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Hypermedia systems have been demonstrated to support authoring and 
reading of mostly static information. Few systems address the needs of analysts 
deriving information from a continuously changing base of information. Those 
that do, focus on the existing content and use links primarily for navigation and 
management. An open hypermedia architecture is proposed for a class of analysis 
systems where the value added by the analyst is through associating data elements. 
In such systems, links are the primary form of information being managed. 

The architecture developed provides a framework through which 
hypermedia analysis systems can be generated with little or no code development. 
Specifically, the model is shown to apply to the domain of software engineering by 
mapping the analysis portions of a rapid prototyping lifecycle to a schema defined 
using the framework. 

Through the addition of n-ary links and links to links, the architecture 
provides a closer mapping to the Dexter Hypertext Reference Model than current 
graph-based models such as the Multimedia Object Retrieval Environment 
(MORE). Improvements over MORE are also shown in the use of abstraction as a 
filtering mechanism and through the full involvement of links as being the primary 
focus of the analysis, query, and filtering functions. 
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I. 



INTRODUCTION 



A. A PATTERN OF ANALYSIS 

In many domains, analysis is an exercise in making connections between pieces of 
information. Physicians providing remote consultations through a telemedicine system can 
be thought of as linking collections of patient encounter information to diagnoses based on 
their experience. The conditions these diagnoses represent have already been discovered 
and described in most cases. In addition, treatment protocols have been developed for 
many of these diagnoses and have been linked to them by medical researchers. The link 
provided by the consultation can have characteristics. For instance, the link might have 
attributes that represent the strength of confidence that the physician has in the diagnosis 
due to the quantity and type of data presented, and the degree to which the physician feels 
the data match expectations. 

Software requirements analysis can be approached in terms of finding elements of 
the system’s domain and their interconnections in the development of or linkage to a 
problem fi-ame [Jackson, 1995]. These concepts are then linked to solutions that either 
have been successfully used within the fi*ame before or are newly developed. The 
individual data elements are not typically being initiated by these analysts, although at 
times new notions might be introduced. The majority of their efforts create associations 
between elements that already exist. 

Analysis of this form can support command and control environments as well. 
Actions, orders, and status can be represented through associations. A military planner 
may choose the best way to engage a hostile unit by evaluating information created by 
intelligence analysts that has been developed using tools working just as telemedicine tools 
might function. The results of the planner’s analysis are recorded in links between targets, 
weapon systems, tactics, and particular preconditions (e.g., weather). Further, once 
presented several alternative plans in this form, a commander may generate an attack order 
by adding an execution link fi’om the plan to the particular unit that is to carry out the 
attack. Autonomous agents looking for the creation of such links can set a series of 
events into plaee to ensure the order is issued and can evaluate the status of the plan. The 
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status can be linked to the plan being executed to allow the commander to maintain 
awareness of the situation. 

The figure below shows how a hypergraph can represent the information provided 
to a commander. Here the targets are being evaluated based on attempts to rniruinize 
coUateral damage. A report detailing how Target #2 can be attacked while reducing the 
risk of collateral damage is presented. To order the attack, the commander might connect 
the target, the tactic, and a platform capable of executing the plan. 




Figure 1. 1 Hypergraph of a Plan 



The descriptions above fit the criteria for a pattern. They describe a problem that 
reoccurs and present the core of a solution that can be used multiple times [Alexander et. 
al., 1977]. In fact, this pattern is illustrated in a famous use case fi’om the memex device 
proposed as World War II was concluding. 

The owner of the memex, let us say, is interested in the origin and 
properties of the bow and arrow. Specifically he is studying why the short 
Turkish bow was apparently superior to the Enghsh long bow in the 
skirmishes of the Crusades. He has dozens of possibly pertinent books and 
articles in his memex. First he runs through an encyclopedia, finds an 
interesting but sketchy article, leaves it projected. Next, in a history, he 
finds another pertinent item, and ties the two together. Thus he goes. 
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building a trail of many items. OccasionaUy he inserts a comment of his 
own, either linking it into the main trail or joining it by a side trail to a 
particular item. When it becomes evident that the elastic properties of 
available materials had a great deal to do with the bow, he branches off on 
a side trail which takes him through textbooks on elasticity and tables of 
physical constants. He inserts a page of longhand analysis of his own. Thus 
he builds a trail of his interest through the maze of materials available to 
him. [Bush, 1945] 

Bush even anticipated the uses of such hypermedia. The future reader is covered 
under another use case, as are link attributes. One attribute of interest to Bush was the 
age of a link and the frequency of its use, allowing links that are accessed more recently to 
be stronger than those that fade with time. Even autonomous agents were envisioned that 
would take care of mechanical actions based on the user’s decisions. [Bush, 1945] 

B. USE OF HYPERMEDIA SYSTEMS FOR SOFTWARE EVOLUTION 

Information generated in this manner can be captured in the form of a hypergraph 
model. The hypergraph model of software evolution is an example [Luqi et. al., 1994] 
[Luqi and Goguen, 1997]. Software analysis is also an exercise in connecting data. 
Though the end goal is to reuse, create or modify software products, the path taken is one 
of matching user needs to software requirements, and software requirements to design 
elements. Throughout this process, analysts create and break associations among pieces 
of information, and in doing so create new information through these structural 
modifications. Each change of the structure has a rationale behind it, right or wrong. 
Each change is an addition to the body of knowledge within the domain. 

One mechanism for automating the management of information modeled in this 
way is through hypermedia systems. Using a hypermedia system that provides both 
authoring and reading tools, analysts can create information that people and autonomous 
agents can access. What hypermedia systems provide is the ability to easily work with a 
wide variety of data while utilizing the powerful information present through the 
structures created by the connections made among the various data items [Numberg, et. 
al., 1997]. They also allow the user of the information (reader) to access the information 
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in ways not necessarily planned by the creator of the information (author). In this way, 
new discoveries can be made from the same body of data as readers with problems 
different from those envisioned by the author look at the hypertext from a different 
perspective. pSfielsen, 1990] 

Modeling associations is not a unique activity to hypermedia system development. 
Object-oriented and relational models also place a great deal of importance on how pieces 
of a domain relate to each other [Rumbaugh et. al., 1991]. Hypermedia stands out in that 
the links stored constitute much of the information content of the system rather than a 
means of connection for objects or entities that embody the focus of the system. Object- 
oriented design methods can prove valuable in developing hypermedia systems once the 
links are defined as objects themselves [Wiil and Leggett, 1997]. 

C. CONTRIBUTION 

Current hypermedia systems and research focus heavily on the reader of 
hypermedia information. A number of search and navigation methods and models have 
been proposed and demonstrated. Yet, these focus on finding and presenting data objects 
or locating an object currently in focus relative to the entire domain. Filters limit the 
objects shown in a display, while link presentation is based upon the object subset 
presented. These approaches downplay the link’s contribution to the hypertext system, 
restricting it to navigation support, rather than treating a link as an atomic unit in the 
development of a structure that represents knowledge within the system. Additionally, 
while data objects and links can be described using object-oriented terms of generalization, 
this attribute is not weU used in presenting the information to the reader. 

Authors’ tool requirements are not well understood beyond the development of 
online training, journalism, and entertainment products. These systems stress the 
nonsequential nature of hypermedia [Nielsen, 1990]. The information content of the 
linkages is an aid to navigation, but also in subtle ways provides information to the user 
concerning what concepts or actions relate to what others. The dynamic nature of an 
analyst’s work is not typically addressed, and tools for authorship that attempt to build a 
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domain structure are targeted at software system developers rather than domain analysts 
as end-users. 

For hypermedia systems to be of value to analysts such as those working in 
software evolution, authorship tools need to have a prominent role. Likewise, links must 
be the focus of searches and filters since the links are the primary form of information 
being dealt with by the analyst. Finally, to scale systems and their user interfaces up to 
handle the complexity of data used by analysts, better use of abstraction needs to be 
employed. 

The main contributions of this thesis are: 

• A hypermedia architecture supporting the analysis of software evolution 
consistent with the Dexter Hypertext Reference Model [Halasz and Schwartz, 
1994]. The model presented focuses on the analyst’s role in creating 
hyperlinks and adds value to the links through the addition of attributes that 
map to the analysis process. 

• Models for user interaction with the hypermedia that treat links as equals to 
data objects in importance to the reader. Searches and filters operate on links 
as well as data objects and enhance the value of the links through the addition 
of attributes that map to the analysis process. 

• The use of abstraction as a filtering technique t(> aid the reader in 
understanding the analysis relevant to the reader’s problem. Links made 
between specialized objects may be of interest to readers \sho never wish to 
look at the specialized objects or links themselves hut are interested in roaming 
the domain at a higher level of abstraction. 

• The ability for a user to dynamically extend a domain ihn>ugh the addition of 
object classes and link types. Entirely new hypetmedui an.it> sis s\ stems can be 
generated with little or no coding. The architecture ph'skIcn a tramework for 
rapidly generating new systems covering new domaias 

• An extension of graph-based query and filter metht»ds |I ucarelb and Zanzi, 
1996] to work with hypergraphs. This addition allov\s better mapping to the 
analysis pattern described earlier, and allots a nupping to the Dexter 
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Hypertext Reference Model, which requires the ability to use n-ary links as 
well as link-to-link connections. 

D. ORGANIZATION OF THESIS 

The rest of this thesis is organized as follows. Chapter II provides a review of 
related research in hypermedia systems and analysis models. For hypermedia, focus is 
given to works that model the underlying architecture for such systems, authoring tools, 
and on user interaction approaches. Hypermedia support for analysis that fit the pattern 
described above are studied to determine what features are essential to provide such 
support through a hypermedia system. Chapter III describes a mathematical model of an 
architecture for hypermedia systems that support analytical efforts in general and software 
engineering in particular. The goal is to provide such support while remaining consistent 
with the Dexter Hypertext Reference Model. Chapter IV describes author/analyst tools 
consistent with the model presented in Chapter III. Tools are described for all the types of 
actions an analyst might make that effect the link storage area structurally. Chapter V 
provides a model for reader interaction with the hypermedia systems generated from the 
framework in Chapter III. Filtering, navigation, and searching operations are all 
considered. As these have been well defined for the data objects themselves, focus is 
given to operating on the links. The use of abstraction for filtering both links and objects 
is demonstrated. Chapter VI demonstrates the use of the architecture as applied to the 
Computer Aided Prototyping System [Luqi and Ketabchi, 1988] in support of software 
requirements analysis. Conclusions and directions for future study are provided in 
Chapter VII. 
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II. TECHNICAL BACKGROUND AND PREVIOUS RESEARCH 



A. HYPERMEDIA 



1. Structural Computing 

a) General 

Representing infonnation structurally is widely used though its importance is not 
always recognized. Researchers in artificial intelligence (AI) have found that different 
structures constitute different knowledge. Knowledge-based systems often use a network 
of interrelated units to represent information [Travers, 1989]. 

Structural computing is a “philosophy of the primacy of structure” [Numberg, et. 
al., 1997]. Most models support the primacy of data objects and allow structures to be 
built through programming. For some problem domains, the structures represent the 
knowledge in the system and the data objects merely play a role as a part of the structure. 
Examples of these domains are argumentation support [Streitz, et. al., 1989], spatial 
hypertext [Marshall and Shipman, 1993], biological taxonomy and linguistics [Numberg, 
et. al., 1997]. In such domains, certain patterns in stmctures are developed firom primitive 
elements and are used to represent relevant information [Jordan, et. al., 1989]. 

b) Hypermedia as a Structural Computing Paradigm 

Hypertext and hypermedia are commonly thought of as databases that allow the 
user to navigate to one item of information fi'om another item. They are conceived of as a 
network of nodes and links where nodes store information and links provide a cross- 
reference. Links are thought of by many as merely providing a means of transport that can 
be activated to allow the user to view the information stored in the connected node. 
[Shneiderman and Kearsley, 1989] 

This definition is limiting. It ignores the information that is created by analysts and 
that C 8 U 1 be represented and stored by linking nodes together. The chemical properties of 
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water differ from those of unbound hydrogen and oxygen atoms. Similarly, structures 
created in hypermedia provide different information than the collection of nodes that form 
a subset of the building blocks used. The results of a domain specific analysis can produce 
much deeper knowledge than the individual nodes could ever represent. 

Hypertext systems through their flexibility offer significant advantages in working 
with structures. Nodes and links can be used to create any conceivable structures when 
typing is not imposed [Nelson, 1992]. The addition of types can provide constraints to the 
structures preventing those that are not acceptable and enriching the information presented 
by those that are created. Flexible systems that support both ideas have also been 
proposed and developed. Recognition is given to the idea that in the initial stages of 
analysis, types may not be known, but that later strong typing of links and nodes may be of 
use to add additional information [Haake, et. al., 1994]. This flexibility can be realized by 
defining all object types in a system to be subtypes of a universal type. This can be done in 
the schemas created through the framework presented in this thesis. When this is done, a 
process of refinement in which general types are replaced by subtspes that are more 
specific can be employed. 

Structural analysis of hypertext has been used to assist the user in navigation. By 
looking at metrics regarding the compactness of clusters of nodes, algorithms can suggest 
where aggregation relationships occur within a hypertext. The analysis ignores the 
contents of the nodes, as well as any possible typing of nodes and links, focusing instead 
on the numbers of links coming into and out of the nodes and comparing these numbers 
with the mean values of these figures for all nodes in the h\pcrtc\t. Improvements in 
clustering are made by looking at the strongly connected compt'oents and biconnected 
components. The result of the algorithm is a tree of clusters. |Botalt>go and Shneiderman, 
1991] 



2. Open Hypermedia 

From 1987 to 1991 researchers noted that the hypertext s> stems of the time did 
not support the needs of collaborative work groups and that thc> e**uld not be integrated 
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into the computing environments being used in large enterprises [Halasz, 1987] [Malcolm, 
et. al., 1991]. Requirements were found for hypermedia systems that were not being 
addressed. These included: 

• Interoperability to access and link information across arbitrary platforms, 
applications, and data sources. 

• Link and node attributes to record who made a link, what the permissions are 
for the particular link or node and other management information. 

• Link anchors that allow attachment to the exact data desired. 

• Link types to provide more information about the meaning of a particular link 
and what functions the link is intended to support. 

• Public and private links to support collaborative environments. 

• Templates for automating routine analysis tasks. 

• Navigational aids that can act as filters and supply powerful querying 
mechanisms. 

• Configuration control so that information of importance in an analysis effort 
can be developed and managed in hypertext. 

To address these requirements, open hypermedia systems evolved. Open 
hypermedia systems have been defined as those that exhibit the following characteristics 
[Davis, et. al., 1992]: 

• A system that does not impose any markup on the data. By marking up data in 
order to create hyperlinks, the data is changed making it inaccessible to 
systems that cannot handle the markup. 

• A system that can be integrated with any tool that runs under the host 
operating system This can be extended to mean a system that can be 
integrated with distributed object environments. 

• A system in which data and processes may be distributed across a network, and 
across hardware platforms. 

• A system in which there is no artificial distinction between readers and authors. 
This is quite important for systems supporting analysis. 

• A system to which new functionality can be easily added. 
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Since analysts are both readers and authors of node content and links, these characteristics 
are vital in a hypermedia system intended to support analysis. Likewise, the ability to link 
objects without changing them is critical. The information being linked together by the 
analysts may be coming from other applications and databases with which the hypermedia 
system has been integrated. These applications will not understand changes imposed on 
the data in order to support linking. The links must be separated from the content. This is 
the basic premise of open hypermedia systems and has been demonstrated in research 
systems such as Microcosm TNG [Goose, et. al., 1995,1997]. 

3. Rich Hypermedia 

Rich Hypermedia systems add attribute information to the structural components 
of the hypermedia. Links and nodes are classified by type and amplifying meta-data may 
be added to them [Osterbye and Normark, 1994]. Topological constraints may be 
imposed on the elements of the hypertext representing the business rules of the domain. 
An example of a constraint that may be employed in requirements engineering (as 
described in Chapter VI) restricts requirement dependency to issues rather than allowing a 
dependency link to criticisms. This implies that user feedback must be analyzed prior to 
affecting the body of requirements, allowing alternative selection to occur. One major 
limitation in agents cited in [Shneiderman and Kearsley, 1989] is that they cannot infer 
information about links other than the fact that there is a connection between two nodes. 
Rich Hypermedia allows more of this information to be easily found as it is stored as part 
of the links and nodes themselves. 

Rich hypermedia systems are usually found in applications targeting specific 
domains. Therefore, the meta-data can be deduced through domain analysis. Examples of 
domains targeted for rich hypermedia to date are software engineering [Osterbye and 
Normark, 1994] [Garg and Scacchi, 1987] and argumentation [Conklin and Begeman, 
1987]. 

Analysis is often performed in domains where information is known that can be 
used to create a rich hypertext. The schemas found in the model in Chapter 111 reflect this 



10 



idea. However, analysis often uncovers situations not previously imagined. For this 
reason the HyperObject Processing Environment (HOPE) model presented in this thesis 
allows the schema to be enhanced without changes to the code or having a negative effect 
on the hypermedia. It is also possible for the author of the schema to include an untyped 
component and untyped link for all others to be derived from. This allows all rules to be 
broken if necessary, while still providing rich information when possible. This can be 
accomplished since components and links that act as though they were outside the schema 
are actually created from classes at a higher level of abstraction. Since class membership 
can be queried, agents can determine whether or not such a situation has occurred. 

4. Spatial Hypermedia 

Structure does not necessarily require explicit links between pieces of information 
in order to exist. Links are the expression of interconnection. However, interconnection 
can be expressed through spatial structure. One benefit of a spatial representation of 
structure is that ambiguity or uncertainty can be represented in this fashion. If hypermedia 
structures are represented by nodes literally being near other nodes for which there exists a 
relationship, then all nodes are to a greater or lesser extent near to all other nodes. 
[Marshall and Shipman, 1993] 

VIKI is a tool for organizing information. Collections of information can be 
created by placing nodes within nodes. Nodes are also placed into groupings that 
correspond to a common relationship, partitioning the information space. [Marshall and 
Shipman, 1 997] 

This approach, while useful in the experiments done in [Marshall and Shipman, 
1997], would not work well in the complex analytical space of software engineering or 
command and control. These would require n-dimensional spaces, and the number of 
relationship types (i.e., n) can be huge. Also, while [Marshall and Shipman, 1997] allowed 
elements to repetitively appear in the spaces, with a large number of relationships, this 
could clearly get out of hand in a tool using spatiaUty for visualization. 
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5. The Dexter Hypertext Reference Model 



The Dexter Hypertext Reference Model (Dexter), was developed to provide a 
basis for comparison among hypermedia systems, and to provide a common foundation on 
which to standardize for interoperable exchange [Halasz and Schwartz, 1994]. Many 
authors make the effort to demonstrate how their architectures map to Dexter. By doing 
so, hypertext researchers have labeled this as an extremely important model. 

The Dexter model defines hypertext systems in terms of a three-layer architecture 
with well-defined interfaces between the layers. These layers are the within-component, 
storage, and run-time layers as shown in the following figure. 

Run-time Layer 

Presentation of the hypertext; user interaction; dynamics 

Presentation Specifications 

Storage Layer 

a ‘database’ containing a network of nodes and links 

Anchoring 

Within-Component Layer 

the content/structure inside the nodes 

Figure 2. 1 Layers of the Dexter Hypertext Reference Model [Halasz and Schwartz, 1994] 

The focus of the model is the storage layer and the two interface layers. The 
storage layer provides the node and link structure that defines hypertext as being a unique 
architecture. The components of this layer are treated as generic containers. The contents 
are ignored and are handled in the within-component layer. The interfece between the 
storage and within-component layers is critical to the model however. It is here that the 
means for addressing locations or items within the content of individual components is 
handled. This is called anchoring. In the case of pure text components, links are not only 
available between components, but between spans of characters. Similar spans can be 
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defined for most media (e.g., spans of video). Likewise, the interface between the storage 
layer and the run-time layer is important. Through presentation specifications, information 
about how a component should be presented to a user or to an application is defined. 
Multiple presentation specifications can be used to allow components to appear in 
different manners depending on who arrived at that component and by what link. [Halasz 
and Schwartz, 1994] [Gronbaek and Trigg, 1994] 

For hyperobjects as described in this document, it will be shown that anchors and 
presentation specifications can be handled through the same mechanism. The objects 
being linked together in the following chapters are not simple text files or other display 
media. They represent aggregate objects fi'om one or more databases, as in the case of an 
issue, requirement, or diagnosis. Therefore, spans of characters do not always provide an 
appropriate anchor for links. Individual fields need to be addressed, and in some cases, 
spans of characters, or other objects, found within a field. Since information about objects 
are always received through methods, anchors and presentation specifications are defined 
through object-oriented design features utilizing methods and their parameters. Design 
patterns are used that allow each object class to provide a difierent set of methods to 
access its data, while not requiring clients to know what type of object is being linked to in 
advance. 

The Dexter reference model while being the most notable model in the field has 
shortcomings. Despite the stated purpose of allowing interchange of hypertext, limitations 
have been foimd. Interchange of hypertext can be accomplished in two basic ways. First, 
hypertext can be exchanged between hypertext systems. Dexter has been shown to 
support this approach. A second approach has been called hypermedia-in-the-large. This 
approach is necessary for large digital libraries or engineering enterprises. It provides a 
fi’amework for allowing aU information in a wide-area network to be utilized with 
hypermedia applications. Rather than provide a single hypertext system as described for 
the Dexter model, a link service is provided. Applications that know how to use the link 
service can access and create hjqDermedia information. The implication is that a data 
model for hypertext cannot be assumed. Dexter has not been shown to be successful in 
supporting hypermedia-in-the-large [Leggett and Schnase, 1994] . 
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In the HOPE architecture a linkable interface definition is used to allow any 
application or service that implements the interface to provide or use link services. The 
basic structure of Dexter is preserved, but the underlying implementation assumption of 
using a firm data model is replaced with the option to have components and links be built 
by implementing interfaces rather than inheriting implementation [Coad and Mayfield, 
1996], 



6. Graph Models, Views and Object Retrieval 

Unstructured hypermedia models have not been seen as suitable for capturing the 
knowledge needed for many applications. The result is extra cognitive overhead for both 
the author and the reader. The author must expend effort in choosing link structures that 
will prevent the reader fi'om getting lost, and often the reader must choose a path carefully 
for the same purpose. As a result, graph-based models that incorporate the notion of 
domain modeling have been introduced. The data modeling aspects, similar to those used 
by database developers, keep the information consistent with the users frame of reference. 
Graph models provide a natural way to model associations that form in hypermedia 
systems. The combination has been used by several researchers. [Lucarella, et. al., 1993] 

a) Multimedia Object Retrieval Environment (MORE) 

MORE uses just such a graph model [Lucarella and Zanzi, 1996]. The model of 
this system’s architecture is defined using the four-tuple M — (Z, O, ^ Zf ). The 
conceptual schema Z is defined by the five-tuple Z = (C, T, A, 9^, ^ itself. The 
conceptual schema is the domain definition for the particular multimedia system. The 
individual elements of these tuples are defined as follows: 

• C is a finite set of class names. 

• r is a finite set of primitive type names that are built into the multimedia 
system. V(t) is the set of values associated with the set where / e T. 

• A is a finite set of attribute names. Attributes may be simple or complex. 
Simple attributes have as their domains a type t e T. Complex attributes have 
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classes c e C as their domains. The schema defines attributes as being either 
single or multiple in order to represent the cardinality of the relationships. 
However this reaUy needs to be a part of the property relationship defined 
below. Regardless, the mathematics of the sets and graphs does not change for 
either MORE or HOPE. It is also not necessarily appropriate in all hypermedia 
systems to provide such a constraint on the attributes. If such constraints are 
truly needed both models may need to be upgraded. 

• xA X (C uT)\s the property relationship. If a, Cj} e then c, has 
the complex attribute a, relating it to class Cj. 

• C X C is the inheritance partial ordering relationship. If (cu c) e then 
Ci is a subclass of Cj. 

• O is the set of instances of objects created within the system. Each object 
belongs to one of the classes c sC. 

• O X Cis the instantiation relationship. If (o, c) € JThen o is an object of 
class c. 

• S'qO xA X (O u V(T)) is the link relationship. If (oj, a, Oj) e-.5^then o/ has 
the attribute a with the value oj. This is only true if either the classes for the 
two objects were related with the attribute a, or the property was inherited 
fi'om ancestral classes. 

Graphs are defined for both the schema and the multimedia information system. Each of 
the graphs is defined as a tuple consisting of a set of nodes and a set of edges. The graph 
for the schema has for its nodes the union of the classes and types sets (C u T). The 
edges are a union of the inheritance and property relationships. Therefore, nodes can be 
connected by an edge either if they are related by virtue of an attribute or if one class is a 
subclass of the other. The graph for M has nodes consisting of the object instances of O 
and the values of the primitive types that are used as attributes for the objects (i.e., V(T)). 
The Edges of M are the link relationship triples defined above. 

This model serves as a starting point for the architecture defined in this thesis. 
HOPE generalizes the graph model to a hypergraph model and provides greater value to 
the links in the graph structures by making them classes with instances as well. By doing 
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this, particular instances of a relationship can be created and retrieved, or included and 
excluded from an overview map of the hypergraph. Additionally, abstraction is used to 
greater benefit both for component nodes and links by filtering out simple attributes that 
are not relevant to the level of abstraction being viewed. 

b) Nested Context Model 

Other models exist that are based on graph structures. These models do not 
extend to the analysis patterns described in Chapter I as well as that for MORE. The 
presentation algorithms are however still interesting and can provide ideas for HOPE 
algorithms. One such model is the Nested Context Model [Casanova, et. al, 1991]. 
Here, the model is quite simple with a set of nodes {N) and set of links (Z). There are two 
basic types of nodes, context nodes and terminal nodes. Terminal nodes are similar to the 
primitive types in the MORE model. Context nodes group sets of terminal and context 
nodes through relationships identified by links. A node may be related to more than one 
context node, thus the result is a directed graph, where every link is a unidirectional edge 
and is an attribute of one context node. To have bi-directional links, both nodes would 
have opposing links defined. This is similar to the property relationship of MORE, 
however, MORE does not view the link as being contained in a node, nor the feature that 
context nodes contain the nodes that are connected to them by links. 

Therefore, the system is divided into multiple hyperdocuments and a particular 
node can be contained in any number of them. This creates a hierarchical description of 
the information where each context node of a particular level is a root, though the root 
may be a lower level context node m a hierarchy defined by another root and vice versa. 

c) HYDESJGN 

The Dexter Hypertext Reference model described above requires the ability to 
handle composite links and components. HYDESIGN [Marmann and Schlageter, 1992] is 
one of the few models to successfully achieve this. The data model for HYDESIGN 
follows an object-oriented class hierarchy. The figure below (drawn using Unified 
Modeling Language [Rational, 1997]) gives a top level view of the model. Atomic nodes 
compare to the primitive types of MORE and HOPE. One of the primary differences is 
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that reference nodes may be created allowing more than one component to share the same 
content. This is not infeasible in the set-based architectures of MORE and the extension 
to HOPE, but is not currently allowed in either. 




Figure 2. 2 HYDESIGN Class Hierarchy [Marmann ami Schlageter. / 992 ] 



The most interesting difference among the models from the standpoint of analysis 
systems is the addition of aggregate links. The extensions to MORI; built into HOPE 
allow for link abstractions. There are three types of aggregate links in in'DESIGN. The 
first is the g-link or general aggregate link. G-links define directed n>oted graphs. When 
creating g-links, three conditions must be met: 

• Source and target node must be of the appropriate t> pes 

• There are no link conflicts with any other aggregate links 

• The resulting network is a directed rooted graph. All n»Kle\ are reachable from 
the root. 

When a g-link is deleted, the system must delete every node that is n»> longer reachable 
from the root. 
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The two other classes of aggregate links are h-links (hierarchical links), and s-hnks 
(sequential links). Hierarchical links are similar to g-links except that they form directed 
rooted trees instead of directed rooted graphs. Sequential links build sequences to define 
particular paths through multimedia resources. These sequences can then be treated as a 
single unit. One basic restriction applies to aggregate links. No node may be part of more 
than one aggregate. 

SBL nodes are another interesting extension on the idea of an aggregate. These 
are high level nodes with all the features of simpler nodes but with three additional 
properties, that of structure, behavior, and locality. Structure determines the way nodes 
and links are connected within the SBL node. Behavior determines the way nodes and 
links react to SBL oriented operations. Locality refers to the way that SBL-nodes can be 
used to define workspaces or local environments through aggregation. An SBL-node may 
define a private workspace for an analyst, or a the global workspace (which the private 
SBL may be a part of). 

The addition of aggregates similar to those in HYDESIGN are a likely 
continuation of the architecture development described in this thesis. However the 
concept of perspective and adequately determining the level of abstraction to show the 
user will be more complicated with these features. HYDESIGN uses a different concept 
for what are termed views. Through the virtual deletion of certain aggregate nodes and 
the concentration on particular localities, areas of the hypermedia are not visible to the 
user. This is a very different approach from perspectives and the abstraction filtering 
proposed in this thesis. The semantics of the creation and deletion rules of aggregate links 
must also be compared to actions taken in analysis to determine if this is an appropriate 
approach for analysis support systems. However it is clear that the use of aggregate links 
and nodes could be used to model the hypergraph structures described in [Luqi, et. al., 
1994] and [Luqi and Goguen, 1997]. 



18 



B. USE OF HYPERMEDIA TO SUPPORT ANALYSIS 



1. Argumentation 

One type of analysis system that has been used for research into hypermedia 
systems has been argumentation support systems. The most notable of these is gIBIS 
[Conklin and Begeman, 1987], Here a hypermedia system was established with a firm 
schema of the sort that can be developed in MORE and HOPE. The schema is 
represented by the figure below. 

Generalizes or Specializes 




Figure 2.3 Schema for IBIS. 



The system (gIBIS) includes capabilities for browsing, context sensitive menus to 
aid users in making legal moves, searches, and multi-user support. There is no support for 
perspectives, nor for extending the schema. The idea behind gIBIS is strict adherence to a 
particular rhetorical style. The lack of perspectives and abstraction however leads to a 
problem with scaling the system up to many nodes as recognized in [ConkUn and 
Begeman, 1987]. The lack of schema extension was noted in that there were times when a 
need for a “meta-discussion” was found. New concepts were handled as annotations 
rather than expanding the schema. 
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Others have found weaknesses in the approaches taken. The need for guidance to 
the analyst and the definition of particular structure patterns representing certain types of 
arguments was noted in [Streitz, et. al., 1989]. The need for particular activity spaces was 
recognized. The SEPIA system includes: 

• Planning Spaces: This space is set up to allow coordination of the entire 
discussion. Posting the initial questions and establishing the structures for 
participants to respond to is among the capabilities supported in this space. 

• Content Spaces: This forms space in which the user accesses content 
concerning the domain and begins to buUd a semantic structure of subject. 

• Argumentation Spaces: This serves as a medium for the discussion of the 
questions to be solved. It is structured as a collection of nodes and links either 
through a schema as fi’om gIBIS or through a schema representing other 
argumentation structures. 

• Rhetorical Spaces: This is a private space that allows the author to structure 
the arguments that are to be presented in the argumentation spaces. Active 
applications that assist the author in constructing structures representing 
particular strategies. 

These aspects of SEPIA are useful for requirements engineering and other analysis 
activities. HOPE allows multiple workspaces through the cxi.stcnce of multiple 
hypermedia structures within the storage layer of the system. The usefulness of 
applications to guide the user through the creation of structures is alM> recognized in the 
HOPE architecture through the allowance of run-time applicatioas that can manipulate 
information using storage layer interfeces. 

2. Software Engineering 

Software engineering has been identified as an acti\it> that can be supported by 
hypermedia systems at least since 1987, in the Intelligent Soft\sare H>perte.\t System (I- 
SHYS) [Garg and Scacchi, 1987]. The system is based around tlK- IX>eunK*nts Integration 
Facility (DIF) which manages software products throughout a systems lifecycle, defining 
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the products through a series of forms and templates. I-SHYS allows active processes to 
aid in the software tasks through the knowledge that products relate to each other in a 
known manner. Agents then can assist analysts in their tasks. 

The approach taken in I-SHYS is similar to that described in Chapter VI of this 
thesis. The application of the HOPE architecture to requirements engineering is done by 
mapping out a schema that describes the interrelation of artifacts and tasks in the 
engineering process. Simple tools are provided to allow user to manipulate the structures. 
However, more intelligent tools can perform task automatically and in support of human 
effort by exploiting the same interfaces. 

I-SHYS also goes further than is demonstrated here in integrating content related 
tools such as a software engineer might use without a hypertext system. However, the 
CAPS environment described in Chapter VI, into which this model is meant to be 
integrated provides the same capabilities. 

The I-SHYS work demonstrates the usefulness of a rich hypertext structure that 
allows autonomous agents to obtain the information needed to provide assistance to the 
analyst. The capabilities shown in I-SHYS, gIBIS, and SEPIA would not be possible 
without a schema illustrating the component and association types of the analysis process 
at hand. 



21 



22 



III. THE MODEL 



A. CONCEPTUAL SCHEMA 

The model presented here for a HyperObject Processing Environment (HOPE) is 
strongly based on the model used in the Multimedia Object Retrieval Environment 
(MORE) [Lucarella, et. al., 1993][Lucarella and Zanzi, 1996]. It has been extended to 
describe a hypergraph rather than a directed graph. This permits a closer mapping to the 
Dexter model than MORE would achieve. The areas lacking in MORE relate to the 
requirement in Dexter for bi-directional and n-ary links. In addition, Dexter requires the 
ability to link to links rather than simply to component nodes. 

The primary means by which this is accomplished is through the addition of the 
Link class. Nodes are distinguished as being component nodes (non-link nodes) or link 
nodes. Links and components become subclasses of a graph’s node class. Now edges 
leaving component nodes do not go directly to other components but are connected to 
links. Likewise, links can have edges to other links. In this way, multiple components on 
either end of a link can be connected together and links can be connected to links. This 
change to the model requires that component nodes of the hypergraph be considered 
adjacent if there are no component nodes between them. The definition of weakly 
connected is likewise affected. A new term, “mildly connected” is also introduced as a 
consequence of this model. 

Another change made to the model is that all classes have a common ancestor 
called Object. This is done in the same sense that Java classes are all derived from the 
class Object [Arnold and Gosling, 1996]. This allows all classes, even those not 
predefined in the schema to be connected using any that does not have a restriction 
limiting connections to a particular subset of classes. This allows the domain extending 
capability described in the introduction. 

Definition 1. The conceptual schema E is defined as the tuple 

r=(C, T,A,S^,Xs^), 

where; 
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• C is a finite set of node classes; each class c e C denotes a structure (in terms 
of attributes) and an extension (the collection of objects that have this 
structure). One element of C is the Link class. In addition, all classes are 
derived fi'om a common ancestor known as Object. This allows the domain- 
extending behavior described above and in the introduction. 

• r is a finite set of content types. These include the types of the implementation 
language, and any other classes defined solely in the within content layer. If 
the type represents content, it is referenced either by a stored query to a 
database, is referenced in a file-system (e.g., using a path), or references a 
universal resource locator (URL) in the World Wide Web. The difference 
between types and classes are that instances of types are not linked to multiple 
nodes in the hypergraph. They form simple attributes or content of nodes. 
Each t eT denotes the type of a primitive object, and V(t) is the set of values 
possible for that type. 

• is a finite set of attributes. Attributes are fimctions defined on classes and 
may be simple or complex. The range of a simple attribute is a basic type t eT 
and the range of a complex attribute is a class c e C. Attributes with multiple 
values (Am) are distinguished fi’om those that are single-valued (^j). A = As u 
Am. 

• ^^(C’ xA xCj u(C xA xT) is the property relationship. C’ is defined as 
follows: c’ e C’ —^c’^C. Here is a significant difference fiom MORE. The 
property relation allows n-ary links between subsets of C and unary links 
between classes and types. If (c, a, Cjj e then the elements of C/ ’ have the 
attribute a, having as the range the classes in c, '. Note that this a will be 
mapped to a particular link class and is therefore explicitly associated with the 
link class. If more than one class is contained within c ’ then this indicates that 
this relationship is only valid when at least one instance of each class is present 
in the relationship. Later in the definition of a hyperobject multimedia system, 
it will be shown that as long as the relationship is defined for each class 
individually, that multiple objects of different classes may participate in such an 
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n-ary relationship without this requirement. Note also that (ci’, a, c/) implies a 
relationship from elements of c,’ /o elements of cf. If (cf, a, cf) e 3^ as well, 
than the relationship can be considered to be bi-directional. Non-directional 
relationships are modeled in the same way as bi-directional with the Link class 
associated by defined below having an attribute specifying how to 
characterize the relationship. 

• C xC 'xs the inheritance partial ordering relationship. If Cj) e .^*^then 
the class c, is a subclass of Cy and inherits attributes. 

• A X C* where C* c C contains the link class and all of its subclasses. 
This is an onto relationship such that if (a, cf) e ^then a is represented by 
linking classes using the link c* . This set serves to map associations to the link 
classes that represent them. 

Definition 2. Given S, the conceptual schema hypergraph is a hypergraph 

H(D = (N, E), 

where: 

• N — C xjT \s the set of nodes. Nodes firom C contain the components and 
links of the hypermedia, while those fi'om T contain the primitive types used by 
component content. For each c e C, where c 0 C* (i.e., component nodes), 
there is a rectangular-shaped node labeled c. For each t e T, there is an oval- 
shaped node labeled t. For those c e C* (i.e., link nodes) the node is 
represented by a line segment. One or more non- link nodes will be connected 
by edges to either end of the line segment. One or more other link nodes will 
be connected to a midpoint of the line segment by an edge as well. 

• £■ is the set of edges. For each (C/, cf e H there is an edge (shown as a bolder 
line than other edges within the user interface) connecting C/ to Cj. This edge is 
directed and has an arrow on the side of the parent class. For each (cf a, cf) 
€ ^here is a link node line segment labeled with a, where the link node is of 
type cf and (a, cf) e j»f There are edges fi'om each element of cf to the first 
endpoint of the link node, and edges fi'om each element of cf to the second. 
As mentioned in the background research, Dexter based systems can have links 
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that are to, from, bi-directional, and non-directional. If a link is to, then the 
arrows of the edges to the first endpoint will point back towards the elements 
of Ci’. If a link is from, then arrows of the edges connecting to the second 
endpoint will point to elements of cj Edges connected to bi-directional links 
will always have arrows pointing back to all of the non-link nodes, and edges 
to non-directional links will not have any arrows. Edges alone connect nodes 
to types. Types do not connect to links. These edges are always unidirectional 
and are presented just as in MORE, as arrows pointing to the type. 

These definitions are more complex than those used in MORE [Lucarella and 
Zanzi, 1996]. The added features implement the characteristics of the hypergraph rather 
than a directed graph. In addition, these definitions give links an equal status with the 
classes/nodes representing content. This is a significant improvement over most models in 
that filtering, searching, and navigation can use links as primary elements rather than 
merely including them if nodes that they connect are present. As presented earlier, links 
are the value-added information of the storage layer in a Dexter-based hypermedia system. 
It is in this realm that analysts work. 

B. MULTIMEDIA INFORMATION SYSTEM 

The conceptual schema and the conceptual schema graph defined above define the 
class structure of the hypergraph object model for the system being developed. To obtain 
the object model, the relationships between classes and their instances as well as between 
instantiated objects must be defined. The class model illustrates what connections can be 
made, while the object model shows what links and attribute values are actually present 
given the state of the user’s analysis. 

Definition 3. The hyperobject multimedia information system (HOMIS) M is 
defined as the tuple 

M= (1,0, .JT^) 

where: 

• 2" is the conceptual schema defined above. 
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• O is the set of objects stored into the system. 

• O X C is the instantiation relationship. Each object o O is an instance of 
a class c e C. Note again that links are members of a class derived from the 
class Link and ultimately from Object. This means that actual links are 
themselves instances and can be treated on an equal footing with other classes 
within user interaction models. 

• -Pt (O’ X 0(A) X O') u (O X A X V(T)) is the link relationship. Paralleling 
the property relationship, sets of objects (O ’ is defined as o ’ e O’ o’ ^ O) 
can be linked to, from, bi-directional, or without direction. 0(A) is the set of 
instances that represent links. If (b, 0(a), o/) e _Sfthen the objects within o, ’ 
have been linked to the elements in Oj ’ with a link relating to an instance of the 
class bound to attribute a m (o, a, V(t)) then o has the attribute a with the 
value V(t). (oj, a, o/) e „^can occur if and only if one of the following 
conditions holds; 

1. For all elements of oj and o/, the elements are instances of some 
classes Ci e cj and Cj e c/ such that (cj, 0(a), c/) € This is valid 
only if Ci ’ and c, ’ are sets with single elements only, or if all elements 
from these sets have object instances in O/ ’ and Oj ’ respectively. 

2. For aU elements of oj and Oy’, the elements are instances of some 
classes c, e cj and Cy e c/ such that (c„ ci) e ^Ck e c*’ and (ck, 
0(a), Cj) 

3. For all elements of oj and oj, the elements are instances of some 
classes c, e cj and cj e Cj ’ such that (c,, cj) € ^Ck e c* ’ and fc, 0(a), 

Ck) 

The conditions above mean that objects can only be related if their classes have 
been defined as being related in the same way either directly or through the inheritance 
relationship. These conditions do allow an n-ary relationship to be built up from several 
unary or smaller n-ary relationships. As stated earlier, these smaller n-ary relationships 
must be satisfied in whole or they are not valid. These rules can be relaxed by a particular 
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system through the use of Object and Link in the schema. This feature can essentially be 
turned on and off if desired. 

Definition 4. Given the HOMIS M, an instance hypergraph is a hypergraph 

H(M) = (N, E), 

where: 

• N = O u V(T) is the set of nodes. Nodes represent components in the Dexter 
model [Halasz and Schwartz, 1994] using rectangles, links using line segments, 
or values using ovals. These are generated from the schema using the 
instantiation relationship. 

• E is the set of edges connecting component objects to link objects, link objects 

to link objects, and objects of any sort to values. For each (oj 0(a), oj ’) u (o, 
a, V(t)) e «?There are edges connecting the nodes, labeled with a and with 
arrows based on the direction of the relationship. If a link is to, then the 
arrows of the edges to the first endpoint will point back towards the elements 
of Oi ’. If a link is from, then arrows of the edges connecting to the second 
endpoint will point to elements of Oj Edges connected to bi-directional links 

will always have arrows pointing back to the non-link nodes, and edges to non- 
directional links will not have any arrows. Edges alone connect nodes to 
types. Types do not connect to links. These edges are always unidirectional 
and are presented as arrows pointing to the type. 

C. RELATED DEFINITIONS 

Decisions on what to present to the user are going to depend on concepts relating 
whether or not particular nodes are connected in a sub-hypergraph created with a 
particular criterion. Since links have been defined as nodes in order to achieve n-ary links 
and link-to-link associations, new definitions with regard to adjacency and connectedness 
are needed. 

Definition 5. Two component (non-link) nodes are adjacent to one another iff, 
there is a path between them that does not include any other non- link nodes. Two link 
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nodes are adjacent if they are directly connected by a single edge. Link and component 
nodes are adjacent to each other if directly connected by a single edge. 

This definition allows us to treat the link as though it were an edge in a 
hypergraph, yet continue to give it the same treatment as other objects with regard to 
searches, linkages, and filters. It is still usefiil at times to consider component nodes as 
being directly related if there are only links between them. 

There could be multiple links between them but no intervening nodes. In many 
cases, this is not a concern and adjacency as defined above is sufficient. However in other 
cases (e.g., annotation links that may be considered of less importance than other 
relationships), we may want to differentiate between those separated by a single link and 
those that can be connected through a variety of links (and perhaps a variety of links and 
nodes). For this purpose, the following definition is supplied. 

Definition 6. Two nodes (link or component) are mildly connected iff there is a 
path fi’om one node to the other, but no path fi’om one to the other can be created without 
adjacent links. 

Definition 7. A hypergraph is weakly connected iff by ignoring the direction of the 
edges, there exists a path fi’om any node to any other node. 

D. ARCHITECTURE 

1. Storage Layer Composition 

The architecture being proposed is a direct translation of the mathematical model 
described above fitted into the Dexter reference model. In designing an implementation of 
this architecture, several options have been found, but the architecture remains a 
description of the sets and tuples of the definitions above. The object model of this 
architecture is described in the OMT [Rumbaugh et. al., 1991] diagrams below. 
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Figure 3. 1 Storage Layer Composition 



The Dexter storage layer is buUt as containing zero to many HOMIS instances. 
Each HOMIS represents M = {Z, O, .if ). The runtime layer must specify which 
hypergraph is being dealt with by specifying which HOMIS is being accessed. There can 
be multiple views of the HOMIS as well as will be described in the model for reader 
interaction. 



The Schema is also composed of sets as described in the model above and the 
diagram below. 




Figure 3.2 Schema Composition 



This architecture allows schemas to be built using a drawing tool in the nm-time 
layer. The implication is that new schemas and therefore new HOMIS can be designed 
without additional code being produced. This is true provided that: 

1. TypeSet (J) contains all of the primitive types needed for the new hypermedia 
system. If not, new code must be written will be to implement the additional 
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types. This includes the definition of new anchor types that are meaningful to 
the primitive type. The anchor indicates a method and offset (if any) to get to 
the content being tied to the component node. As the types are built up, new 
analysis systems can be rapidly created. 

2. No new non-content attributes are required concerning the instances of the 
components and links. These are part of the tuples stored in the ObjectSet so 
the definition of the tuple class being used would need to be modified. 

The sets themselves need to contain strings, pairs, and triples. The PropertySet 
contains two types of triples adding some complexity, though this can be implemented 
easily in polymorphic languages. 

Methods for the storage layer are listed in the following table. The initial 13 
methods are required to be consistent with the Dexter reference model [Halasz and 
Schwartz, 1994]. Those methods after are added due to the richer nature of the model for 
a HOMIS. Not .only must inheritance be accounted for, but methods to manipulate the 



schema are provided. 



Storage Layer Methods 


CreateComponent 


Creates a new component and adds it to the h>pcnext. 


CreateAtom icCom ponent 


Creates a new atomic component. 


CreateLinkComponent 


Creates a new link. 


CreateCompositeComponent 


Creates a new composite component if the atomic 
components and the composite being created agree with 
the schema. 


CreateNewComponent 


Invoked from the run-type layer, and calls one of 
CreateAtom icCom ponent, Createl.inkCtim ponent, or 

CreateCompositeComponent. 


DeleteComponent 


Deletes a component, ensuring that an> links uhose 
specifiers resolve to that component are renuned 


ModifyComponent 


Modifies the non-content attributes (eg. cTcatuwi date) of 
a component while ensuring that its asMKuied mhcmation 
remains unchanged, that its type (atom. link, or compc»sitc) 
remains unchanged, and that the rcNulun^ hsperiext 
remains link consistent. 


GetComponent 


Returns a component from the comp^wiCTU v unique 
identifier. 


AttributeValue 


Takes a component and an attribute, and rciums the value 
of the attribute. This refers to the primitive t\pe m the 
HOMIS model. The language between Dexta and MORE 
conflict. 


Set Attr ibuteValue 


Takes a component identifier, a value of an anrihute. and 
sets the value of the attribute. 
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All Attributes 


Returns an enumeration of all the attribute values of the 
component passed to the method. 


LinksToAnchor 


Takes an anchor and its containing component, and returns 
the set of links that refer to the anchor. 


LinksTo 


Takes a hypertext and a component identifier and returns 
the identifiers of links resolving to that component. 


AddClass 


Adds a class to the schema. 


DeleteClass 


Deletes a class fi*om the schema 


AddType 


Add a primitive type to the schema 


DeleteType 


Delete a primitive type from the schema 


AddAttribute 


Add an attribute to the schema. This can be either an 



attribute that links two classes together, or an attribute that 
links a class to a primitive type, 



DeleteAttribute 


Delete an attribute from the schema 


AddProperty 


Establishes that a link can exist among from a set of 
classes to another set of classes using an established 
attribute. Can also link an class to a primitive type using 
an established attribute. 


DeleteProperty 


Deletes a link between class sets or between a class and a 
type within the schema. 


Addinheritance 


Add an inheritance relationship from one class to another. 


Deleteinheritance 


Delete an inheritance relationship. 


ListHOMIS 


Provide an enumeration of hypermedia systems kept within 
the storage layer. 



Table 3. 1 Storage Layer Methods 



2. Within Content Layer 

The within content layer is structured as a collection of primitives. These primitive 
types include those typically implemented in programming languages or their libraries 
(e.g., integer or string), and those that are unique to multimedia systems (e.g., mpeg or 
hypertext markup language). Objects for each of these primitives are written and 
containers are built for each. These containers and objects can understand the anchors 
being passed to them. When an object in this layer is passed an anchor, it returns an object 
of the expected type. This object can be utilized by presentation specification methods to 
display the contents for the node of a hypergraph. 
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E. BENEFIT SUMMARY FOR THE HOMIS MODEL 



There are several benefits of the HOMIS model over existing graph-based 
hypermedia system models. 

1. Closer Mapping to Dexter 

The HOMIS model includes features that map to the Dexter Hypertext Reference 
Model [Halasz and Schwartz, 1994] that are not found in existing graph-based hypermedia 
system models (e.g., MORE [Lucarella and Zanzi, 1996]). 

Dexter calls for n-ary links, which are not possible in simple graph-based models. 
By extending the model to a hypergraph, n-ary links become feasible. Dexter’s links must 
also be able to be attached directly to other links with no intervening components. This is 
contrary to the mathematics of graph-based models. However, by allowing links to be 
nodes themselves this becomes possible. HOMIS distinguishes between link nodes and 
component nodes in order to differentiate between content and associations to preserve 
the hypermedia feature of the architectme. 

The final improvement is the decoupling of content from the storage layer or 
hypermedia services themselves. MORE and others treat content the same as other 
attributes of component nodes. This is a common feature of object and graph based 
hypermedia systems that use data objects linked together rather than more traditional 
media objects (text, video, and audio). The result is a tight coupling between the content 
of the nodes and the hypermedia structures being created by the authors or analysts. 
Dexter is an open hypermedia architecture and thus allows attributes of components and 
links to be separated from the content being represented by the components. In this way 
immutable objects held within the within content layer of Dexter are not affected by the 
analyst’s work. The analyst is truly adding valuable information exclusively through the 
authoring of links. 
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2. Less Discrimination Against Links 



If authors of hypermedia are adding value through the creation of links and not 
through the modification of the content referenced by the nodes, why is it that most 
search, navigation, and filtering methods act primarily against the attributes and content of 
components. By creating Link classes that are treated in a similar manner as component 
nodes, links are placed level with content in importance and in visibility. This model will 
assist in developing filtering, navigation, and search tools that focus on the links. Links 
can now have attributes and can be manipulated independently of the nodes they connect. 
However, the model still preserves the meaning of a link by tying links to associations that 
must exist between the nodes they connect. Similarly, research into structural computing 
may benefit from this model as the structures created through combinations of links and 
components are of more interest than the content referenced by nodes. 

3. Richer Modeling of Domains 

Some domains are more easily modeled using hypergraphs than graphs. This is 
true of software evolution [Luqi, et. al., 1994] and military planning. The lack of n-ary 
links and link-to-link connections does not prohibit the modeling of these undertakings. 
By adding placeholder components absent of meaningful content but connected to the 
necessary nodes, one can model the same information. These placeholder components 
must have rules associated with them that indicate how the relationships that they 
represent work. However, this approach adds complexity to the view provided to the 
user, and since under older models, components are the primary objects, adds clutter 
rather than meaning. By extending the graph model of hypertext to a hypergraph model, 
these domains are more cleanly and expressively defined. 

4. Use as a Framework 

The HOMIS model and architecture provides a means of building a storage layer 
that does not need new code for each instance of a hypermedia system. Users can enter 



34 



schemas to represent the analysis to be done. Only if new primitive types are employed 
must code be written. This is necessary since the storage layer must communicate with 
the within-content layer to retrieve data of the appropriate type. Presentation 
specifications for the type must also be created to provide methods for interacting with the 
data. 
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IV. ANALYST TOOLS 



This chapter looks at the run-time layer operations affecting a HyperObject 
Multimedia Information System (HOMIS). The HOMIS is manipulated through calls to 
the storage layer as defined in the last chapter. The following operations are required by 
the Dexter Hypertext reference model [Halasz and Schwartz, 1994]. 



Run-Time Layer Operations 


OpenSession 


Creates a session for a given hypermedia. 


OpenComponent 


Opens a set of new instantiations on a given set of 
components. 


PresentComponent 


Takes a specifier and a presentation specification and 
creates an instantiation for the associated component. 


FollowLink 


Uses openComponents to present any components referred 
to by the “TO” specifiers of any links with anchors 
represented by a given link marker. 


NewComponent 


Opens a new instantiation on a newly created component. 


Un Present 


Removes an instantiation 


Editinstantiation 


Edits an instantiation. A call to realizeEdits is required to 
save the changes. 


RelizeEdits 


Saves an instantiation’s editing changes to the 
corresponding component by calling ModifyComponent. 


DeleteComponent 


Deletes the component associated with a given 
instantiation. Also removes any other instantiations for 
that component. 


CloseSession 


Closes a given session. Note that by default, pending 
changes to instantiations are not saved. 



Table 4. 1 Dexter Run-time operations 



As with the storage layer, the HOPE model allows some operations in addition to 
these minimum requirements. While the model behind MORE [LucareUa and Zanzi, 1996] 
is geared towards the reading of a static hypermedia, the HOPE model is intended to 
support dynamic analysis. The operations described below represent the required set and 
those extensions believed needed to support analysts’ use of hypermedia. Use cases 
supporting these operations defined for the software engineering domain are found in 
Appendix B. 
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A. OPEN AND CLOSE A SESSION 



The HyperObject Processing Environment (HOPE) can store multiple 
HyperObject Multimedia Systems (HOMIS) within its storage layer. Each HOMIS 
represents the information described by a single hypergraph. Therefore, the openSession 
operation of Dexter is implemented such that the particular HOMIS to be used is chosen 
from the storage layer. This can be done by providing a selection of HOMIS discovered 
using the listHOMIS method. A new session can also be created that defines a new 
HOMIS. 

Closing a session always prompts a user to save the modifications made to the 
HOMIS before ending. This operation calls the relizeEdits operation required of Dexter 
based systems. 

B. CREATE AND MODIFY THE SCHEMA 

This is not a capability required by the Dexter reference model. While typed links 
and components are supported, they are not required nor is there a requirement for a 
framework to be built that allows new schemas to be created without resorting to coding. 
However, manipulating the schema sets are no different than manipubting the instance 
sets. Actions in the graph view of the schema correspond to changes in the sets in the 
storage layer. Additionally, manipulating the schema for purposes of setting perspectives 
is merely an extension of the capability to draw and edit a schema. Many of the 
interactions that the user performs within HOPE are with the sclk.*nu. making this an 
important run-time tool. 

C. ADD OR EDIT A COMPONENT NODE 

Not all component information will already exist. TlK>ugh the premise of the 
architecture is that much of this information comes from ouiskle the hypermedia 
architecture, some is clearly initiated by users of HOPE. In the case of requirements 
analysis discussed in the use cases and Chapter VI, users must enter criticisms and project 
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managers must enter demonstration plans. Editing is allowed only sometimes. For the 
most part HOPE considers component node content as immutable. Anchor logic in the 
within content layer controls whether write methods are available. Likewise, anchors can 
force new nodes to be created when information changes from underneath the system. 
This again stems from the notion that much of the information is controlled by other 
systems with which HOPE must integrate. Presentation specifications for components 
control the behavior concerning how the information is presented to and edited by the 
user. If the component’s content is immutable, then the run-time application must actually 
“spawn” a new instance through the storage layer, making intelligent decisions as to what 
links to carry forward to the new version, and what type of links to make between the old 
and new versions. 

D. LINK NODES TOGETHER (INCLUDES DELETING OR MODIFYING A 
LINK) 



This is the basic representation of the analysts’ effort. Run-time tools need to be in 
place to allow the user to graphically or through searches, create links between 
components, between links, and between components and links. Basic tools can 
graphically allow link creation. The tool can check to see what links are allowed between 
two items selected by querying the properties set of the HOMIS’ schema ). Task 
specific applications can help make links based on the actions taken by participants in the 
activity. 

An example is a criticism entry tool for requirements engineering (see Chapter VI). 
Such a tool can create criticism content, create a new component node, then create a link 
to the component node representing a user who has the same name or email address of the 
person who submitted the criticism. This can be done either with direct usage of a HOPE 
based system, or by an autonomous agent that acts upon receiving criticism content by 
electronic mail from the user. 
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E. VIEW AND FILTER THE HYPERGRAPH 



This subject is handled in depth in Chapter V. In Chapter VI it is shown that in 
any real analysis can quickly result in a hypergraph that cannot be displayed. Filtering the 
screen to see the information of use is important. Since a HOMIS has a schema as well as 
instance sets, the hypergraph shown to the user can be filtered both through choosing the 
types of content of interest as well as particular values of interest. 

F. EXAMINE A COMPONENT OR LINK NODE 

Examining a node allows one to view the contents or attributes of the node. In 
this model, such content is in the form of “simple” attributes, associations with primitive 
data elements found in the within content layer through anchors. Therefore, there is no 
one element that makes up the content of a node, but there may be any number of such 
attributes. Therefore, users examine attributes through selection of the attribute nodes in 
the hypergraph. The attributes shown are based on the perspective pattern being viewed. 
Instances of classes that extend other classes only display the attributes inherited fi’om the 
level of abstraction selected for the particular perspective(this is described in more detail in 
Chapter V). 

G. FOLLOW A LINK 

Any run-time application that is working with a node can query the storage layer 
with the FollowLink method. If c is the current node and c eX, the storage layer returns 
the set of links of the form 
(X a, Y) 

where (X, a, Y) is an element of =Sf Given that the HOPE model includes the concept of 
perspective, ^cdcci be filtered to include only those links that are present in an instance set 
5 e S' of the perspective P(7t, S), described in Chapter V. 

Since a link node associates sets of nodes (where a node can be either a 
component or link), the application must choose which node to travel to. This can be as 
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simple as presenting the list of nodes to a user for choice. Likewise, the application might 
be written to treat the set as an enumeration and provide all of the nodes to requestor 
either sequentially or simultaneously. Finally, the application may have an algorithm by 
which a subset of the nodes are chosen. 

H. FIND COMPONENT AND LINK NODES 

Searching for particular elements of a database is a common activity. As the 
hypermedia base is a form of database [Wiil and Leggett, 1997], it is not surprising that 
this would be common in HOPE as well. Most hypermedia systems support searching for 
component nodes. By treating links in the same manner as components, links can be the 
subject of searches as well. Link classes have instances, which can have attribute values, 
making them suitable targets for searches. 

Both kinds of nodes are typed in HOPE. As a result, searches look for instances 
of a particular class, associated with either: 

• Simple attributes of a particular primitive type holding a particular value 

• Complex attributes that have particular simple attribute values associated with 
them. 

It is also possible to fashion query capabilities that will use the navigation capabilities 
described above (FoUowLink) to move from node to node that at least satisfy some 
particular navigation criteria in search of a target node that meets the actual search 
criteria. 

I. DISTANCE AND COMPLEXITY MEASUREMENTS 

These capabilities are not usually discussed relative to hypermedia architectures. 
The need for this capability is suggested in the use cases on alternatives analysis in 
Appendix B. Two mechanical methods of comparing suggested alternative solutions to 
issues (as described in the schema for CAPS in Chapter VI) are presented in [Ibrahim, 
1996]. The first measures the scope of a proposed change by counting the number of 
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modules affected by the change, directly and indirectly. In a HOPE based system, this is 
done by travelling the affects links from an issue and counting the number of component 
nodes involved. This involves using the FoUowLink interface to the storage layer. The 
second measurement is done by looking at the maximum distance that a module resides 
away from the issue being resolved. The method of implementing this measurement is the 
same as for the previous one. Following links, an application keeps count of the links 
traveled until a module no longer affects any others. 
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V. 



INFORMATION RETRIEVAL 



A. READER’S GOAL 

The reader of hypermedia information has one basic goal in mind; to find the 
information needed to accomplish a particular task. This basic goal is independent of the 
nature of the reader. The reader could be human or an autonomous agent. The reader 
could be searching for information in order to make a decision that will only impact 
entities outside the systems automation boundary. Alternatively, the reader could be an 
analyst who once finding the information sought, will link it to another item, changing the 
contents of the system. 

Regardless, readers of hypermedia have two basic modes of information retrieval 
available to them, search and browsing. Often users will accomplish their tasks using 
some combination of these two methods. [Nielsen, 1990] 

Each of these methods has advantages and disadvantages. In order to be efficient, 
searching requires that a user understand: 

• a query language, 

• the structure of the information held within the system. 

• and, the particular goals of the query. 

The first two of these requirements poses the difficulty that the user is required to know 
too much about the implementation of the system. However, searching: using a query can 
provide an immediate tinswer when a well-structured query Is properly evaluated 
[Lucarella and Zanzi, 1996]. 

Browsing allows the user to view the contents of a comp^nvnt. then using links, 
decide upon another component to view. If the authors ha\c created links that match the 
thought process needed to extract the information desired, this can proceed efficiently. 
The reader has no need for knowledge of the information structure or a query language. 
The user does not even need to know precisely what is being v»ught. nK*rely be able to 
recognize when it has been found. However, if the links are not \scll suited to the problem 
being addressed, disorientation of the user results [Marmann and Schlageter. 1992]. 
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B. OVERVIEW DIAGRAMS 



Overview graphics can perform multiple functions. Since hypermedia systems are 
often used through browsing and navigation, overview graphics can provide a sense of 
what information is nearby and place the user’s focus in context to the entire information 
base. In some systems, the reader can acquire information directly through the overview 
diagram. [Nielsen, 1995] [Tochtermann and Dittrich, 1992] 

HOPE based systems are intended to provide this capability. Since the analytical 
information being represented is provided by the linking of nodes together, seeing what 
information is connected provides a great deal of the information in the system. The 
overview diagram provides a view of the analysis being performed. It also provides the 
basis for graphical search capabilities described below. 

1. Simple Hypergraph View 

Any graph based overview diagram is possible using the HOPE architecture. The 
primary view that is provided in the trial implementation is a simple display of the 
hypergraph. Later in this section the concept of perspective and filtering are discussed to 
show how this view is made more useful. At its simplest however, the view is provided a 
set of object instances and a set of links. From this a hypergraph is drawn following the 
convention in [Lucarella and Zanzi, 1996]. 

All component nodes (representing the elements of the set ObjectSet or O in the 
HOMIS) are drawn as rectangles. Attributes of the objects that refer to primitive types 
(or members of T) are drawn as ellipses. An edge with an arrowhead is drawn fi'om the 
object to the node representing the value of the type. The edge is labeled with the 
attribute name. Links fi’om one object to another are drawn as line segments. Each line 
segment has three attachment points, two on the ends and one in the middle. The point in 
the middle is for attaching edges to other links. The endpoints are for attaching edges to 
component nodes (representing the objects). Arrowheads are provided where direction is 
defined. An example diagram follows: 
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Figure 5. 1 Overview Diagram Example 

Note that when the values V(t) are simple enough to show within the ellipse they are, 
while an identifier is shown otherwise. 

2. Graphical Queries 

In MORE and HOPE, to specify classes of objects, the user interacts with the 
schema to select component or link nodes of interest. HOPE differs from MORE in that 
the level of abstraction can be chosen by the user. Attributes relating to the level of 
abstraction are the only ones displayed. Those from subclasses are hidden. 

To indicate instances that contain a particular value, the user again interacts with 
the schema (or more accurately with the perspective pattern described below). The user 
selects the simple attribute of the class and is given an input window to enter a value for 
the primitive type. Objects where V(t) equals that value can then be retrieved . This is 
shown in the following figure, where the criticism analysis perspective from Chapter VI is 
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being used to retrieve only criticisms posed by a user with the email address of 
dlange@nosc. mil. 



Full Boolean statements can be described in this manner and used for simple object 
retrieval or to set filters as described below. None of this differs from [Lucarella and 
Zanzi, 1996]. The basic mode of information retrieval supported by MORE is to 
successively filter the information in this way untU the information of interest is easily 
visible in the resulting perspective view. In this way, the user does not need to formulate 
the entire query based on knowledge of the schema. Results are accomplished by 
graphically filtering the information. It is easier for a user to recognize when successive 
filtering has resulted in the information required than it is for the user to formulate a 
suitable query without in depth knowledge of the entire schema. 

However, differences do exist between the MORE and HOPE models. The HOPE 
model allows two additional graphical capabilities. The first is filtering through 
abstraction. Since users and sponsors are both examples of people, they share certain 
attributes. Other attributes are unique to the specific type of people. A query where the 
class people is selected rather than users and sponsors would provide all of the same 
instances, but would only offer the common attributes for filtering. Where only users are 
truly of interest, this class may be chosen, hiding all of the sponsors and showing all of the 
users’ attributes (those inherited as well as those that are unique). It is proposed here, hut 
not proven, that this will enhance the ability of the user to find the information desired. A 
study of this would need to be conducted to determine if this is true. Any query that can 




Figure 5.2 Graphical Query 
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be described through standard query languages can be created using perspective 
interaction. If a mistake is made in selecting levels of abstraction early in the successive 
filtering process, the query desired may not be possible. The user must go back to that 
stage and set a different perspective pattern or filter. 

The second difference is that links are classes in HOPE just as are component 
nodes. The analyst may select links for the purpose of establishing a perspective pattern. 
Likewise, links can have simple attributes and these may be used to filter the information. 
Given that HOPE is intended to provide service to analysts who are more interested in the 
association of information than the raw information itself, it is believed that this will be a 
significant improvement. 

C. PERSPECTIVE AND FILTERING 

The concept of perspective is defined in [Lucarella and Zanzi, 1996] as a means to 
focus the overview diagram on the component nodes of interest to the reader. Perspective 
is a form of data abstraction that provides the user the ability to select a particular portion 
of the schema that is of interest. Only object instances that conform to this schema subset 
are displayed to the user. Perspectives can be predefined and stored for later use. A 
software requirements analyst can use a perspective that focuses on user criticisms and the 
issues they represent (see schema in Chapter VI) while ignoring the connections between 
issues, software requirements, and design elements until ready to address issue solutions. 
The perspective is built by selecting nodes on the graph in MORE or in HOPE by selecting 
either nodes or links. 

Two changes are introduced in the perspective definition for HOPE. 

1. Abstraction is preserved in the perspective. In MORE, selection of an 
ancestral class implies selection of the descendants. This does not allow the 
user to set abstraction at appropriate levels for different pieces of information. 
In HOPE, ancestral class selection allows the objects of descendent classes to 
be displayed, but the attributes shown are based only on those inherited firom 
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the selected class. In essence, all objects are treated as though they were direct 
instances of the chosen class. 

2. The focus on component nodes is supplemented with a perspective based on 
the relationship function. In MORE, nodes are selected and links are included 
if they are associated with the nodes. In an analysis system, the perspective is 
just as likely to be based on the associations themselves. In this case, nodes 
are brought in if they are relevant to the associations. 

1. Definition of Perspective 

Definition 8. Given a HyperObject Multimedia Information System (HOMIS), a 
perspective P is defined as P(n, S), where: 

• 7c is the perspective pattern. The pattern is a weakly connected sub-hypergraph 
of the schema 2” aU of whose link nodes have edges attached to both endpoints. 
N(?r) ^N(S) denotes the subset of the schema nodes (classes, types, and links) 
included in the perspective. E(7t) c E(I) denotes the set of edges associated 
with the perspective. 

• S is the set of object hypergraphs generated by the perspective hypergraph 
through the instantiation relationship. Given s € S, each node (component or 
link) o € N(s) is an instance of the corresponding node c € N(k) or (c, c’) e 
^ ’ where ^ ’ is the transitive closure of ^and c ’ e N(n). If c e N(7t) then 
the type t € N(k) where (c, a, t) e Otherwise, if c’ is the member of N(k), 
and objects of c are used only because of inheritance, then t e N(7 t) only if (c 
a, t) G 3^. The edge (Oi, a, Oj) e E(s) iff the edge (c,, a, c) e E(7t). 

Since links are given the same standing as component nodes in HOPE, the link 
associations can be a selection criteria for perspectives as easily as the components can. 
The second portion of the definition hides primitive type attributes that are found in 
descendants of a selected class. This allows the objects of descendent classes to be treated 
as instances of the ancestor that was selected for the perspective. 
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2. Filtering 



The purpose of a filter is to refine the view provided by a perspective to a subset of 
pattern instances. The user is allowed to choose which of the object instances (by 
attribute values) should be shovvii. The display is already limited to particular node (both 
component and link) types based on the perspective. As in previous sections, the basis for 
these definitions are [Lucarella and Zanzi, 1 996]. The definitions are modified to account 
for the changes made to the model in support of hypergraphs, the Dexter Hypertext 
Reference Mode, and the need for more focus on links in support of analysis. 

Definition 9: Given a perspective P(7t, S),o. filter F is defined in terms of a set of 
selection conditions (Ci, C„} over the pattern. Let a/ be an attribute of type t 
pertaining to a node (class) n, in the pattern tt, then Cy represents a selection condition 
over the actual values of the corresponding object instances. The selection condition is a 
Boolean combination of simple expressions comparing two values a, and Oj. 

The user interface for setting such a filter allows the user to “cUck” on a node, then 
on the attribute to be tested. A window asking for a particular value and providing valid 
comparison operator choices is presented for the user to fill in. 

Consistent with the goals throughout this thesis, the objects being evaluated can be 
link objects as well as component objects. Link objects can also have attributes that can 
be compared. The semantics of such mixed queries work as well. Since the component 
and link nodes are tied (or associated) to each other by edges in the graph, they are treated 
just as all node objects are in [Lucarella and Zanzi, 1996]. Likewise, abstraction is 
supported by this approach. The only attributes that are made available to the user are 
those inherited fi-om the classes chosen for the perspective. Therefore, the level of detail 
is maintained through the filter operation. 

Definition 10: Given a perspective P(7t, S) and a filter F defined over P, a 

selection operation cr returns a subset R ^ S of pattern instances matching the filter: A 
pattern instance 5 matches the filter iff it satisfies all of the conditions C. 

Definition 11: Perspectives are compatible if they have the same pattern but 
different instance sets. 
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Compatible perspectives are used primarily in perspective operations. The primary 
example of this is in the overlay operation defined later. By knowing that the pattern (or 
subset of the schema graph) is identical, the operation can combine object instances that 
pass through different filters. This serves as a union operation on the instances alone and 
can only be done if the patterns are the same and therefore from compatible perspectives. 

The concept of perspective requires further research. The filters defined above 
only take into account the values of attributes with primitive types. However, attributes 
connecting to components and mildly connected to components containing particular 
content could work. In addition, filters that are based on attributes connecting targeted 
structures of sub-hypergraphs could be defined as well. 

Graphical searches work in the same way as filtering. A search is merely a filter 
that intends to allow through only those elements relating to the search criteria. In this 
case it is not for the purpose of reducing clutter in an overview diagram, but for returning 
particular components or links. 

3. Other Operations on Perspectives 

Perspectives have the same form as schemas and are therefore visible through the 
same viewers. Likewise, perspectives can be further refined using perspective selection 
since as a legitimate schema, the operations on a schema are valid on the perspective. The 
foUowing definitions provide the operations defined in [Lucarella and /anzi. 1 996] using 
the modified structures that support hypergraphs. 

Definition 12. Let Pl(^i, Si) and P2(7T2, St) be two perspeemes. with ki ^ ut and 
N(ni) n NOttt) ^ 0. A composition operation over the set of nodes \ n N(n 2 ) 

generates the perspective P(7t, S) = composition(P i, Pt) where 

• ;r is the pattern that results from taking the unions t»l iIk- tH*des and the edges 

of the individual patterns. Therefore, N(7t) = ^ axkl E(7t) = E(ni) 

uE(n2). 

• iS is the set of instances of the pattern n, created b\ finding instance sets such 
that if a node appears in both patterns the refer to tlx- sanx- object instance. 



50 



For all of the classes N’ = N(ni) n N(n:2), two instances can only be part of the 
composition if they share the same object instances. 

The differences between the two models shows up here as in previous definitions. 
Nodes include “link nodes” in the HOPE model. Therefore, composition can occur on the 
relationships between component objects as well as the component objects themselves. 
The result is that composition continues to work with the links having a more significant 
role. Hypergraphs are also supported in this way. This also shows that having instances 
of links does not interfere with processing the hypermedia. 

Definition 13 . Let Pi(7Ti, Sj) and P2(J^2, S2) be two compatible perspectives. This 
means that ;t/ = ;t2, but Si ^82. An operation overlay (Pi, P2) = P(k, S) where: 

• n\ = 7t2 

• S={s\ssSiVseS2} 

This is essentially the union of all instances between two perspectives with 
different filters but the same pattern. Again, the inclusion of association nodes to support 
the hypergraph and treating links similarly to components, does not pose any problems to 
the mathematics originally created for perspectives on simple hypermedia graphs. 

The next three definitions provide operations that are important characteristics of 
hypermedia systems, whether or not an overview graphic is provided. Here browsing is 
done firom the perspective overview in order to determine what objects are available fi'om 
a particular class and present through a particular filter. Navigation on the other hand is 
conducted fi'om an instance to another instance that exists within a particular perspective. 
Two differences fiom the graph model in [Lucarella and Zanzi, 1996 ] are important to 
note. First, browsing and navigation can return link objects in addition to component 
objects. This may not be intuitive and run-time tools may need to be developed that 
behave differently. If a user “clicks” on a link node in the perspective view of the schema 
and is given a list of link instances, the run-time tools will have to decide what to do when 
the user selects one of elements in the list. Different tools legitimately could provide 
different results. Options include: 



51 



• Show a graph including the link and all of the components connected to that 
link. Mildly connected components and the links that create the paths could be 
shown as well. 

• Allow the user to navigate (also defined below) in the direction of the link and 
be presented with a list of components that could be visited. The revised 
definition of adjacency presented in Chapter 111 becomes of interest as the tool 
must decide what to display to the user in the case of a link-to-link situation. 

Second, the navigation operation must consider the revised definition of adjacency and the 
presence of n-ary links. Since links-to-links are possible, adjacent component nodes are 
the targets of navigation, not the links that connect them. This may seem like an 
abandonment of focus on links and a reversion to primacy of node content, but it is not. 
This is the one operation for which links truly are merely a path to follow, as the name of 
the operation suggests. N-ary links must be handled by giving the user a choice of 
components to navigate to. This is particularly interesting with regard to reverse 
navigation. It is feasible to navigate fi-om one node to another across a link, then to 
reverse navigate but to end up at a different component. However, this is consistent with 
the semantics of the n-ary links. N-ary links establish a common association between two 
sets of components, not just in the type of association, but in the instance of the 
association as well. 

Definition 14. Given a perspective P(7t, S), let c € N(;r) he a node (either a 
component or link class). A browsing operation ^ returns all of the relative object 
instances for c within the HOMIS that are included in one of the pattern instances s e S: 

^c(P) - {o\o =^c) A o sN(s)} 

Definition 15. Given a perspective P(;r, S), let o be a displayed object (either 
component or link) in the instance s g S, and let a be one of its complex attributes. Then 
a navigation operation ./fretums the linked objects: 

jPa(o)(P) = {o’\ 3 Y, Z such that o e Y a o’ e Z a (Y, a, Z) e S' a o ’ s N(s)} 
Definition 16. Given a perspective P(tc, S), let o be a displayed object (either 
component or link) in the instance s e S, and let a be one of its complex attributes. Then 
a reverse navigation operation returns the linked objects: 
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-yf'a(o)(P) = (o’\ 3 Y, Z such that o e Y a o’ e Z a (Z, a, Y) e 3 Ya o ’ e N(s)} 

The navigation and reverse navigation definitions differ substantially from those in 
the original model in that that the relationships in ,5^are of the form (set, association, set) 
instead of (element, association, element). 

D. USER INTERFACE DESIGN ISSUES 



1. Consistency 

Consistency of the user interface is vital to reducing the cognitive load on the user. 
Since querying will primarily be done through successive filters, it is important the coding 
of the symbols shown the user remains the same throughout each iteration. Colors and 
shapes represent important information to the user as to what type of object is being 
shown [Galitz, 1993]. Therefore, if rectangles are used for object instances in one version 
of the graph they must be used in aU successive versions. Likewise color changes must 
not occur. It could be possible to create run-time applications that assign different color 
codes to each level of abstraction in a class hierarchy. As the user moves up and down 
these levels in setting perspectives and filters all interactions must retain the same color 
coding. Therefore, color coding should either be added to the model in the storage layer 
or should be calculated consistently among run-time applications from storage layer 
attributes. 

2. Coding 

In the examples produced so far, only simple coding is used. The model could be 
enhanced to code different classes with different shapes or colors. An example might be 
to include an icon with each class type. In this way people could be represented by images 
of people, text can be indicated by some sort of text icon. Different types of links could 
be distinguished by different colors. Inheritance is already coded in the schema graph 
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through a thicker line than that used for other edges. Therefore, this technique should not 
also be used for other meanings. [Mayhew, 1992] 

One coding aspect that is commonly used in hypermedia research is length of edge 
in a graph to indicate the closeness in terms of association of two pieces of information. 
Longer edges imply that the two nodes are not as closely related as shorter edges. Given 
the difficulty in finding a graph display that will draw nodes and edges in a visible manner 
given that different analysts are adding information under different perspectives, this does 
not appear useful for dynamic hypermedia. One coding option for these “fish-eye views” 
[Tochtermann. and Dittrich, 1992] is to use color intensity. The more intense the 
component, link, and edges, the more closely related the information. 

Particular implementation of HOPE architectures are going to need to establish 
coding conventions for developers of run-time software. The integration of already 
produced software could complicate this issue,, but these modules are more likely to be 
dealing with content rather than the hypermedia structures themselves. 

3. Access to Schema 

Many types of users might use the hypermedia systems built using the HOPE 
architecture. Not all may be comfortable with the graph view. The run-time layer offers 
the opportunity for a wide variety of applications to be produced that interact with 
individual user types in a manner that is appropriate for their job. Those who will only 
pose criticisms can interact through a simple form window and never see the hypermedia 
structures underneath. Those who are responsible for connecting items could view 
individual components and have link options made available through a menu. Once again 
they do not need to view the hypergraph. However there is considerable research that 
indicates that providing the hypergraph perspectives to the user will actually make their 
job easier [Nielsen, 1995]. 
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VI. APPLICATION TO SOFTWARE REQUIREMENTS ANALYSIS 



A. COMPUTER AIDED PROTOTYPING SYSTEM (CAPS) 

Software engineering is an analytical activity that fits the pattern described earlier. 
In particular the requirements analysis process, where one must trace user needs to 
software requirements and requirements to design decisions and components is a natural 
fit for this pattern. A model for such analysis has been developed for use with the 
Computer Aided Prototyping System (CAPS) [Ibrahim, 1996]. CAPS is an integration of 
software engineering tools developed to support research in software engineering and to 
assist software engineers in the development of real-time prototypes. The software 
lifecycle supported is shown in the following figure. 

I 



Initial goals 




Figure 6.1 Prototyping life cycle. [Luqi and Berzins, 1988] 
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In this model, the requirements are not assumed correct and complete at the 
beginning of the project. Instead, an iterative process of developing prototypes, 
demonstrating them to the users, and evaluating their responses is used to incrementally 
improve the requirements set. An evolution process is needed to manage the analysis of 
these inputs and ensure that improvement is made with each cycle. Formal model-based 
tools to support such a process are vital to keeping the integrity of a project through each 
cycle. This is particularly important in large projects where multiple analysts and 
designers work concurrently. [Luqi and Goguen, 1997] 

The hypergraph [Luqi, et. al, 1994] model of software evolution was introduced 
in an earlier form as a graph model [Luqi, 1990]. In both models, there are two main 
types of elements that are the primitives fi-om which all others are described. These are 
software components and evolution steps. Initially, only components and steps that dealt 
with software design were described in the model. Ibrahim extended the model to include 
components and steps relative to the requirements analysis aspects of the prototyping 
lifecycle [Ibrahim, 1996]. Ibrahim’s component extensions included the actors in the 
lifecycle processes. In this thesis the model is described in terms of an object-oriented 
hypermedia architecture [Schwabe, et. al, 1995]. Steps are further described in terms of 
run-time layer applications that support analysis efforts. 

The Prototype System Design Language (PSDL) [Luqi, et. al., 1988] forms the 
basis for CAPS. PSDL models the timing and control constraints of real-time software 
and can be used to automatically generate Ada code for prototype implementations of a 
system. CAPS is structured as an integrated collection of software tools grouped in the 
subsystems shown in the figure below [Luqi and Ketabchi, 1988]. 

The Evolution Control System (ECS) controls and manages software components 
and development team interactions. The initial version of the ECS handled version control 
of PSDL components and the scheduling of developer tasks. [Badr and Luqi, 1994] 
Subsequent work added requirements management steps and artifacts to the system 
[Ibrahim, 1996]. 
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Figure 6.2 CAPS Structure [Ibrahim, 1996] 



B. DECISION SUPPORT MECHANISMS FOR CAPS 

Software evolution encompasses the activities that change a software system and 
the relationships among those activities. These include requirements analysis, 
modifications to existing components, and many other activities [Luqi and Goguen, 1997]. 
Change occurs throughout the lifecycle of software products. Software evolution 
processes manage and steer such change. In the model used by CAPS, change motivates 
the use of a prototyping process that interleaves evolution activities with development 
[Luqi, 1989]. 

The evolution control system of CAPS is intended to support the following 
capabilities listed in [Ibrahim, 1996]: 

1 . Planning the prototype demonstration. 

2. Mapping user criticisms into the primitives of a formalized model to be 
analyzed and elaborated so that they can be synthesized into a set of issues to 
be resolved. 

3. Analyzing alternatives available and choosing among them to make necessary 
modifications in the design to resolve the open issues. 
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4. Creating analysis activities. Plan and execute these activities when the needed 
resources are available. 

5. Controlling the evolution of the requirement components that are directly 
affected, as well as propagating the implied effects of the changes and 
configuring the whole requirements hierarchy accordingly. 

6. Propagating any changes in requirements to the affected parts of the system 
design and implementation. 

7. Coordinating the effort of the design team. 

8. Controlling versioning and configuration management to faithfully reflect the 
intended effect of the dynamic ongoing changes. 

Actors and use cases developed to better understand these requirements are provided in 
Appendices A and B respectively. The methods and formats used are derived fi'om 
[Jacobsen, et. al., 1992], [Rumbaugh, et. al., 1991], and [Awad, et. al., 1996]. 

Steps are initiated automatically through dependencies in the model. As will be 
shown, the ability of the HOPE architecture to support links-to-links is used to link steps 
to the associations that cause their initiation. 

All steps have states. The states used are listed below and shown in the diagram 
that follows [Badr and Luqi, 1994]: 

1. Proposed: The initial state of a newly created step. In this state a step is 
subjected to cost and benefit analysis. 

2. Approved: The work to be accomplished has been approved by the manager 
and scheduling attributes such as priorities, required skills, and effort estimates 
have been determined. 

3. Scheduled: The step has been scheduled for implementation and expected 
starting and finish times are calculated. 

4. Assigned: A step has been assigned to a designer or analyst and the work is in 
progress. 

5. Completed: In this state the output of the step has been verified, and an 
immutable version has been entered into the project database. 
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6. Abandoned: The step has been cancelled before it has been completed. It is 
reachable from all other states except the “Completed” state. 




Figure 6.3 ECS Step States 



The inputs and outputs of these steps are described below [Ibrahim, 1996]. 

1 . Criticisms: These are comments provided by users concerning their evaluation 
of a prototype resulting from a demonstration. The criticism can be linked by 
the user to a particular scenario, demonstration, or prototype. 

2. Issues: Issues are created using criticisms posed by users. They are one of the 
intermediate results of analyzing criticisms. Issues represent the problems to 
be solved. 

3. Requirements: These describe alternative means by which issues can be 

solved. An alternative is selected when a particular set of requirements is 
approved by the project manager. 

4. Module: Modules represent the design elements of the system. These can be 
PSDL components, Ada code, or any other form of implementation of a set of 
requirements. 
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5. Demonstration; A demonstration is set up by a project manager. It 
incorporates a series of test scenarios, and is intended to demonstrate a 
particular set of requirements that have been implemented. 

6. Scenario: A scenario is a series of user-system interactions designed to 

demonstrate the satisfaction of a particular set of requirements solving a 
particular set of issues. It is intended to guide a user’s examination of a system 
prototype. 

7. Prototype: A prototype represents a collection of design modules that 

together represent a version of the system being developed. The entire 
prototype is examined by the user during a demonstration. 

All of these objects are immutable once the step that creates them is completed. Once 
created their content is not permitted to be changed in any way. Their status may 
however change. It is for this reason that status is captured as a separate component node 
class. This provides a history of a project through its artifacts. In order to effect change, 
new versions are created. Links between artifacts are permitted to be changed. 
Associations among the elements are the primary contributions of the analysts involved. 
One of the challenges in using hypermedia for software engineering is determining how to 
handle changes to associations when there are multiple versions of a product. The choice 
made here has been to replicate links to each new version, then only change the links on 
the current versions being analyzed. Links to previous versions become immutable when 
the steps producing those previous versions enter the completed state. 

The associations used in the model are: 

1 . PartOf: This type of link connects objects of the same type and represents the 
decomposition structure of software components or steps. 

2. Uses: Links components to show that either the semantics or implementation 
of one is affected by the other. 

3. Primarylnput: Links an object to be updated to a step that will create a new 
version of the object. 

4. Secondaryinput: Links an object to steps that need read-only access to the 
object. 
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5. Affects: Links a criticism to an issue or an issue to a requirements component 
that it affects. This is relation is explicitly declared by an analyst or designer. 

6. Poses: Links a user to a criticism that he or she poses. 

These associations are supplemented with some new ones that better express the 
relationships between items in a hypermedia model. Some of these relationships did not 
make sense in a non-hypermedia interpretation as originally created. These associations 
are: 

1 . Criticizes: Indicates the object of the user’s criticism. Different from affects in 
that it does not cause a ripple effect when a change occurs. 

2. AssignedTo: This was a treated as an attribute within an object in the object 
model and was left out as an inter-object relationship between steps and 
people. 

3. Collects: An inverse of secondary input. 

4. Spawns: Unique to this hypermedia approach to immutable objects and 

therefore not in Ibrahim’s or Badr’s models. Spawns is a relationship between 
a version of an object and a future version that is created from it. By using this 
relationship, links to the parent version can be used to navigate to newer 
versions. Likewise, algorithms can decide when to cop> links possessed by the 
parent object to the spawned object. 

5. Initiates: Connects a step to the association that caused it to be necessary. All 
previous models described the steps as associations, here ibe> are components 
and initiates is the association to a new step (implemented as link-to-link). For 
example, when a user submits a criticism of a prtnot\pe. an analysis step 
finding the issues related to the criticism must be initialed I Ik- analysis step is 
a component that has been initiated by the action taken b> tlx- user to submit 
the criticism. Therefore, it is related to the associatK>n between the user and 
the criticism and thus a link to a link (see Figure 6. 1 0 ) 

6. hasState: Using the state pattern [Gamma, et. al.. IW5| [Free. IW5], state is 
represented as an object separate from the step iliai it is describing. The 
association hasState provides the connection. 



61 



7. Demonstrates: This is a special case of uses. 

8. Tests: Like demonstrates this is a special case of uses. 

The schema that creates these objects and relationships is shown below in OMT 
notation. 




Figure 6.4 Humans 




Figure 6.5 Steps 
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Figure 6.6 Artifacts 




As stated in Chapter III, the conceptual schema for this hyperobject multimedia 
analysis system \s Z = (C, T, A, ^ ). 

C = {Person, User, Analyst, Designer, Step, Analysis, Design, Substep, 
CriticismAnalysis, IssueAnalysis, RequirementAnalysis, poses. 

Criticism, criticizes, assignedTo, affects, collects, uses. Issue, 

Prototype, Demonstration, spawns, demonstrates, Module, 

Requirement, partOf Scenario, initiates, StepState, 

ProjectMemher, tests, hasState} 

T = {String, PSDL, Boolean} 

Note that T is being kept minimal here. No further types are required to 
implement the prototyping method, though they may be used to enhance the information 
presented to the analysts. 

A = {poses, criticizes, assignedTo, affects, collects, uses, spawns, partOf, 
name, email, description, period, version, code, organization, 
initiates, hasState, state, skills, busy, demonstrates, tests} 

{(User, organization. String), (Person, name. String). 

(Person, email, String), (Criticism, description. String). 

({User}, poses, {Criticism}), 

({poses}, initiates, {CriticismAnalysis}), 

({Step}, hasState, {StepState}), (StepState, state. String). 

(ProjectMemher, skills. String), (ProjectMemher. busy. Boolean), 
({CriticismAnalysis}, assignedTo, {Analyst}), 

({Criticism}, criticizes, {Prototype}), 

({Criticism}, criticizes, {Demonstration}), 

({Criticism}, criticizes, {Scenario}), 

(Prototype, version. String), 

(Demonstration, period. String), (Scenario, description String). 

(Issue, description. String), ({Issue}, spawns. llssue!i 
({affects}, initiates, {IssueAnalysis}), 

({IssueAnalysis}, assignedTo, {Analyst}), 

({Issue}, affects, {Requirement}), 

({affects}, initiates, {RequirementAnalysis} ) 

({RequirementAnalysis}, assignedTo, {Analyst }i 
({Requirement}, uses, {Requirement}) 

({Requirement}, partOf, {Requirement}), 

({Requirement}, spawns, {Requirement}), 

(Requirement, description. String), 

({Requirement}, affects, {Module}), (Module, code. PSDL). 
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({affects}, initiates, {Design}), 

({Design}, assignedTo, {Designer}), 

({Module}, uses, {Module}), ({Module}, spawns, {Module}), 
({Module}, partOf {Module}), 

({Demonstration}, demonstrates, {Prototype}), 

({Prototype}, spawns, {Prototype}), 

({Prototype}, collects, {Module}), 

({Demonstration}, uses, {Scenario}) 

({Scenario}, spawns, {Scenario}), 

({Scenario}, tests, {Requirement}), ({Step}, uses, {Substep})} 

{(User, Person), (CriticismAnalysis, Analysis), (Analysis, Step), 
(Analyst, ProjectMember), (ProjectMember, Person), 
(IssueAnalysis, Analysis), (Requirement Analysis, Analysis), 
(Design, Step), (Designer, ProjectMember) , (Substep, Step)} 

cS/= {poses, initiates, hasState, assignedTo, criticizes, affects, spawns, 
uses, partOf, demonstrates, tests} 



1. Requirements Analysis Process Overview 



The analysis phase of the prototype cycle is shown in the figure below [Ibrahim, 

1996], 
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To Design Change Phase 

i 



Figure 6 . 7 Requirements Analysis Process Schematic 



2. Initial Requirements 

The lifecycle of a project starts when an initial set of requirements has been 
collected. For the sake of iUustration, we will create a HOMIS to be the project database 
of a prototyping project. There is one analyst, one designer, and two users for this 
prototyping project. An initial set of two requirements has been collected and entered into 
the system. The HOMIS for this project would start off as described below. 



M=(I, 



I is described above. 

O = {userl, user!, anall, designerl, reql, req2} 
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S- {(userl. User), (user2, User), (anall. Analyst), (designerl. Designer), 

(reql. Requirement), (req2. Requirement)} 

{(userl, name, stringl), (userl, email, string2), 

(userl, organization, stringS), (user2, name, string4), 

(user 2, email, stringS), (user 2, organization, string6), 

(anall, name, string?), (anall, email, stringS), 

(anall, skills, stringQ), (anall, busy, booleanl), 

(designerl, name, stringl 0), (designerl, email, stringl 1), 

(designerl, skills, stringl2), (designerl, busy, boolean2), 

(reql, description, stringB), (req2, description, stringl4) } 

typen (e.g., stringN) indicates an anchor to an instance of a particular type t. This 
ties an object to a particular V(t) found in the within-content layer of HOPE. 

The first steps to be performed are design steps. If one design step is being 
performed to handle both of the initial requirements, then after the assignment to the 
designer the sets would look like the following (relevant to their initial states). 

0 = 0 u {design 1, stepstatel, hasStatel, assignment 1} 

{(designl, Design), (stepstatel, StepState), (hasStatel, hasState), 
(assignment!, assignedTo)} 

2^= S'u {({designl}, assignment!, {designerl}), ({designl, hasStatel, 
{stepstatel}), (stepstatel, state, stringl 5)} 

The anchor stepstatel would point to a state object that represents that the step has been 
assigned. 

After the design of the modules has been completed, the check in of the modules 
changes the links and content of the components. The state of the design step is changed 
to completed, but no change occurs in the sets above for that to happen, stepstatel is a 
mutable object in the within content layer and can be modified once retrieved. The final 
action taken is that the module that is entered into the project database is connected to the 
requirements that affected it. The assignment connection is left as it was as a record of 
who performed the design. Since the assignment is fi'om a step with a completed state 
now, we can easily filter the display to prevent its appearance if desired. 

0 = 0 u {module 1, affects 1, affects2, initiatesl} 
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,J^u ((module 1, Module), (affectsl, affects), (affects 1, affects), 

(initiates], initiates)} 

(({reql}, affectsl, (module!}), ((req2}, affects2, (module!}), 

(module!, code, PSDL!), 

((affects!, affects2}, initiates!, (design!})} 

At the end of this step the hypergraph representing these sets would appear as 
follows: 
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state 




Figure 6.8 Hypergraph after initial development. 
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3. Demonstration Step 



As specified in [Ibrahim, 1996] the demonstration step is to proceed as follows. 
Test scenarios are run with the users using the protot)^e to be reviewed. Their criticisms 
are recorded, reviewed for accuracy, and recorded in the project database. These are to 
be associated with the users who posed them along with any amplifying information. The 
comments must also be linked to the scenarios and version of the prototype being 
demonstrated. 

Specific use cases are provided in Appendix B. One aspect that immediately 
becomes apparent in use case analysis of this step is how much easier preparing for the 
demonstration becomes with hypermedia tools available. 

Demonstrations for users should be matched to their concerns and to their 
expertise. In a non-hypermedia environment, one would need to search for issues of a 
particular nature, or criticisms posed by a particular user. Queries would then be issued to 
find requirements traced to those, or involving the same keywords. In the hypermedia 
architecture being proposed here, one could merely link a demonstration object to the 
issues. Agents that can follow particular types of links and recognize particular structures 
can find the scenarios that have been previously linked to the requirements found to be 
associated with the issues of interest to a particular user. 

Before the demonstration can proceed, test scenarios need to be developed and a 
demonstration planned. 

0 = 0 u (scenario!, demol, tests!, tests2, uses!, proto!, demonstrates!, 
collects!} 

{(scenario!. Scenario), (demo!. Demonstration), (tests!, tests), 

(tests2, tests), (uses!, uses), (proto!. Prototype), 

(demonstrates!, demonstrates), (collects!, collects)} 

5f= 5Pu {({scenario!}, tests!, {req!}), ({scenario!}, tests2, {req2}), 

(scenario!, description, string! 6), (demo !, period, string!?), 

({demo!}, uses!, {scenario!}), 

({demo!}, demonstrates!, {proto!}), (proto!, version, string!8), 

({proto!}, collects, {module!})} 
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The semantics of when to use an n-ary link and when to use separate links deal 
with whether or not the n relationships will ever be divided into individual relationships. 
In the initial development step, the relationship of the two requirements to the single 
module initiated the single design step. Therefore, a single link that included both 
requirements on the from end was appropriate. In developing the test scenario and 
planning the demonstration, the desire to reuse the scenario in the future and the 
recognition that either one or both of the first two requirements could change (in future 
versions) leads to the use of individual links. 

Once the demonstration has been executed the user enters criticisms that are linked 
by run-time tools to the appropriate scenarios, demonstration, or prototype, depending 
how specific the user wishes to be. The creation of criticisms initiates criticism analysis 
steps that begin in the proposed state. After reviewing the criticisms for clarity, 
plausibility, and consistency, the steps are moved into the approved state, then get 
scheduled. Finally, the analysis of criticisms is assignedTo eca Analyst. 

0-0 u{posesl, criticisml, criticizes 1, initiates2, critanall, hasState2, 
stepstate2, poses2, criticism2, critisizes2, initiatesS, critanal2, 
hasStateS, stepstateS} 

{(poses 1, poses), (criticisml, Criticism), (critisizes 1 , criticizes), 
(initiates2, initiates), (critanall, CriticismAnalysis), (hasState2, 
hasState), (stepstate2, StepState), 

(poses2, poses), (criticism2. Criticism), (critisizes2, criticizes), 

(initiates3, initiates), (critanaU, CriticismAnalysis), (hasStateS, 
hasState), (stepstateS, StepState)} 

{({userl}, posesl, {criticisml}), 

(criticisml, description, stringl9), 

({criticisml}, criticizes, {protol}), 

({criticizes 1}, initiates 2, {critanall}), 

({critanall}, hasState2, {stepstate2}), (stepstate2, state, string21), 

({user2}, poses2, {criticism2}), 

(criticism2, description, string20), 

({criticism2}, criticizes, {scenariol}), 

({criticizes2}, initiates 3, {critanal2}), 

({critanal2}, hasStateS, {stepstateS}), (stepstateS, state, string22), 
({critanal2}, assignments, {anall})} 

The hypergraph could appear as in the figure below. 
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Figure 6. 9 Hypergraph after the demonstration step 



Overview diagrams like the one above are too complex for the user to make use 
of. As the number of components and links increases it becomes difiBcult for the analyst to 
utilize such diagrams. For this reason, diagrams that follow will use perspectives to limit 
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the hypergraph to the information needed. This will help simplify the diagram and help 
focus attention on the most important points. Likewise, analysts would do the same. 

4. Criticism Analysis Step 

When the demonstration step is completed, and criticisms have been assigned, 
analysis is performed to extract issues from the criticisms. If issues already exist, the 
analyst wants to connect criticisms to those issues if possible. Therefore, issues and 
criticisms are both part of the perspective of the analyst. The user’s themselves are part of 
the perspective as it is possible that criticisms from multiple users contradict each other or 
contradict issues brought about by past criticisms of other users. Using HOPE tools, we 
can predefine a perspective for criticism analysis. We do this using the schema and 
“clicking” on those component and link classes that are of interest to the analyst in this 
situation. Those selected are: 

• poses 

• criticizes 

• Issue 

• Criticism 

If we had more entries in the project database at this point a filter uould be necessary as 
well. We will have entries to filter out later in the scenario. 1 he resulting h\pergraph is 
shown below. 
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Figure 6.10 Criticism Analysis Perspective 

The analyst finds the issue in the criticism assigned and creates an issue object. 
The criticism is linked to the issue using the affects relationship and a new IssueAnalysis is 
initiated based on that action. The IssueAnalysis begins in the proposed state and is 
eventually scheduled and assigned. The criticism posed by userl is then assigned to the 
analyst who decides that the criticism affects the same issue and does not require the issue 
to be reworked. The criticism is joined to the same link used by the other criticism in 
order to prevent a separate issue analysis fi’om being created. The alternative if the two 
were different but revolved around the same issue would be to spawn a new issue and 
attach the second criticism to that new version of the issue. The run-time application then 
knows to attach links for those relationships of the previous version to the new version. 
The criticism analysis is now completed. 

0 = 0 u{affects3, issuel, initiates4, issueanall, hasState4, stepstate4} 

{(affectsS, affects), (issuel, Issue), (initiates4, initiates), 

(issueanall , IssueAnalysis), (hasState4, hasState), 

(stepstate4, StepState)} 

5f = ,2'u {({criticism2, criticisml}, affectsS, {issuel}), 

({affects3}, initiates4, {issueanall}), 

({issueanal4}, hasState4, {stepstate4}). 
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(stepstate4, state, string23), ({critanal2}, assignments, {anall}), 
({issueanall}, assignment4, {anall})} 




stnng2 




stnngl 




email 







organization— user1 



-poses-* 




string 19 



description 






description 



criticizesi 




affects3 



protol 




-versions string 18 



user2 


— poses2— ► 


criticism2 


— critidzes2- 




scenariol 















— descripl 




stnngie 



Figure 6.1 1 After Criticism Analysis 



5. Issue Analysis Step 

A new perspective is needed for this step. Issues and requirements are what are 
important here. There is less of a connection to the users, but the criticisms posed and the 
connection their relationship to the prototype and scenarios may still be useful to the 
analyst. The perspective for issue analysis is shown below. The perspective pattern 
classes are: 

N(n) = (Criticism, Prototype, Scenario, demonstrates. Issue, Module, 
Requirement, tests, collects, criticizes} 

The purpose of this step is to determine what requirements are affected by the 
issues presented. There are multiple ways to solve any issue, so many alternatives may 
need to be explored by the analyst. Here the benefit of public vs. private links is shown. 
By keeping links private, an analyst can explore multiple solutions without affecting other 
workers. Decision aids such as those described in the following section can be used to 
choose the best option. Once an option is chosen, those links are made public. Again the 
value added by the analyst is mostly in the creation of links. 
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Here the issue is determined to be best solved by modifying requirement!. 
Requirements are immutable so a new version of the requirement must be spawned. Run- 
time applications performing this function must know what connections to keep constant 
and what to move over to the new version. The analyst decides that the scenario does not 
fully test the new requirement, so a new scenario will have to be developed. 



O = O u {affects4, spawnsl, req3, affectsS, affects6, spawns!, tests3, 
tests4, reqanall, hasStateS, stepstateS, initiates 5} 

{(affects4, affects), (spawnsl, spawns), (req3. Requirement), 
(affects5, affects), (affects6, affects), (spawns!, spawns), 

(tests! , tests), (tests4, tests), (reqanall. Requirement Analysis), 
(hasStateS, hasState), (stepstateS, StepState), (initiates!, initiates)} 

{({reql}, spawnsl, {req3}), ({issuelj, affects4, {req3}), 

(req3, description, string!4), ({req3}, affects!, {modulel}), 
({scenariol}, spawns!, (scenario!)), 

(scenario!, description, string!!), 

({scenario!}, tests!, {req!}), ({scenario!}, tests4, {req!}), 
({affects!}, initiates!, {reqanall}), 

({reqanall}, hasState!, {stepstate!}), (stepstate!, stale. string!6)} 
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string 19 



protol — version tringlS 





Figure 6.12 Issue Analysis Perspective 



C. DECISION SUPPORT TOOLS USING HYPERMEDIA APPROACHES 

The remaining steps of analysis and design proceed in a similar fashion to those 
described above. Unique perspective patterns may be employed for each step. These are 
stored and retrieved allowing the analyst to easily work on the job at hand. This section 
describes some of the perspectives necessary to assist stakeholders of a prototype system 
being developed. One of the benefits of perspectives is that it may be possible to handle 
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many of the anticipated user interactions through a perspective view, eliminating the need 
to write code for additional run-time tools. There will be situations where it is desirable to 
have a very job-specific run-time application available to guide the user through a set of 
interactions with the hypermedia. 

1. User Examination of Criticisms 

Users will periodically want to check on the status of the criticisms they have 
posed. They will want to know if the criticism has been analyzed, what the issue was that 
was created or modified based on the criticism, and what version of the system might 
demonstrate correction of their concerns. 

By selecting the following components and links fi'om perspective view a 
perspective for the user can be created: 

• Poses. This causes user, criticism and criticism analysis nodes to be brought in, 
but does not bring in links between criticisms and scenarios, demonstrations 
and prototypes. The state nodes for the analysis are also selected. 

• Affects. By selecting the affects link between Criticism and Issue, issue and 
issue analysis nodes are brought into the perspective. The state nodes for these 
analysis are also selected. 

• Requirements. We select Requirements, Scenarios, Demonstrations, and 
Prototypes to complete the picture. 

The resulting perspective pattern is defined as follows: 

N(n) — {User, poses. Criticism, CriticismAnalysis, initiates, hasState, 

StepState, affects, Issue, IssueAnalysis, RequirementsAnalysis, 
Requirement, Scenario, tests, uses. Demonstration, demonstrates. 
Prototype} 

One issue this example points out is that since links have classes themselves and 
they can appear connecting multiple types of nodes, selecting them once will indicate their 
presence in the pattern in all places where they maintain a weakly connected graph, even if 
not desired elsewhere in the pattern. Schema designers need to take care to only reuse the 
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same association name when the association is truly the same. This is the reason that new 
association names were introduced beyond those used by Ibrahim. Conceivably there will 
be times when a designer does not want to use the same name twice anywhere in the 
schema. 

Given such a perspective pattern, a filter set for the name attribute of User 
equaling a particular string will limit the display to all criticisms posed by a particular user, 
the issues and requirements they relate to, and the prototypes, demonstrations and 
scenarios that show the solutions. The states of all the analyses initiated based on these 
artifacts. The user can then inspect the issues that were derived from the criticisms and 
check to see what versions of the system should contain solutions. 

2. Manager Checks Ongoing Analysis Efforts 

Another perspective can address a manager’s need to see what analysts are 
assigned to what analysis efforts. In this case the perspective pattern is set by selecting 
asssignedTo and hasState as a minimum. This provides a pattern that appears as in the 
following sets: 

N(n) = {Analyst, assignedTo, CriticismAnalysis, IssueAnalysis, 
RequirementsAnalysis, hasState, StepStateJ 

By filtering to only show busy = True analysts, the manager can see what work is 
currently being done. 
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VII. CONCLUSION AND DIRECTION FOR FUTURE RESEARCH 



A. HOPE ARCHITECTURE 

In this thesis, the architecture used for MORE [Lucarella and Zanzi, 1996] has 
been modified to work with a hypergraph instead of a graph model. All of the operations 
developed for MORE have been redesigned for hypergraphs in HOPE. As hypergraph 
models can be used to describe analysis patterns [Luqi, et. al., 1994] [Luqi and Goguen, 
1997] this aids in the use of the hypermedia system in supporting analysis. 

This extension of the model has also allowed a closer mapping to the Dexter 
Hypertext Reference Model [Halasz and Schwartz, 1994], which is intended to support 
application integration into hypermedia systems and hypermedia transportability. Dexter 
requires support for n-ary links and link-to-hnk connections. Support for composites was 
not addressed in HOPE and is another area where MORE falls short of the Dexter 
requirements. This is another area for follow-up research. Composites within the 
hypergraph model will essentially create another type of abstraction (in this case based on 
aggregation) for the model and displays. It is suspected that the mathematical model will 
need further evolution to support this capability. 

Link integrity between the storage layer and the within content layer has not been 
adequately solved by any of the research reviewed for this thesis. This thesis does not 
provide a solution either. The problem is complicated for analysis systems in that a 
change to the contents of a node may invalidate a link made between components by an 
analyst. It is vital that link integrity solutions be explored with analysis systems in mind. 

The method used to develop the hypergraph model has had the additional benefit 
of putting links on an equal footing with component nodes. Links can be abstracted, 
filtered, linked, searched for, and returned to run-time applications. This is important to 
analysis applications as the links represent the value added by the analyst. 

Most hypermedia research systems have focused on designs for non-sequential 
authoring and reading. Some analysis support has been done for argumentation and 
software engineering. However, this is perhaps the first example of a fi'amework for easily 
constructing hypermedia analysis support systems. 
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Finally, HOPE allows multiple hyperobject multimedia systems to reside within the 
same storage layer. This can be used to define private workspaces for analysts working 
particular problems. The results of their efforts should be merged with a HOMIS 
representing the general knowledge of the project, or multiple HOMIS should be able to 
be “virtually merged” indicating areas of overlap and connection. In order for an analyst 
to experiment with multiple solutions to a criticism, such private spaces need to be 
established. The answer actually selected needs to be brought back into the hypermedia 
structure. 

B. PRESENTATION ISSUES 

This effort extended some of the presentation options previously available through 
graph-based hypermedia models. Abstraction is used to improve the filtering ability of the 
user, and links are a legitimate focus of perspectives and filtering options. Previous 
research efforts [Nielson, 1995] [Marshall and Shipman, 1993, 1997] demonstrated that 
overview graphs of hypermedia systems enhance user understanding. The work in this 
thesis made use of that research as well as work that demonstrated methods to improve 
user comprehension of queries through visual representation [Consens and Mendelzon, 
1989] [Lucarella and Zanzi, 1996]. What is not known is whether the use of abstraction 
will be comprehended by the user. Research should be done to see whether hiding 
information through the use of abstraction actually makes the job of the analyst become 
easier or more difficult. 

Some other aspects need more research. In particular the positioning of nodes and 
links in a fi’ame is made more difficult by the analysis use of the hypermedia. Positions 
cannot be stored with nodes as is done in other systems since modification of the 
hypermedia can be done by multiple users all working under different perspectives. With 
different perspectives set, the positioning of the nodes and links would need to be different 
for each of the users. Others are working on algorithms for automatically positioning 
nodes and edges of graphs. At least one of these need to be integrated with HOPE tools 



82 



for evaluation. The systems built using HOPE are not yet fully capable of being used with 
even modest amounts of information until such a capability is included. 

Another area for future research is defining filters based on complex attributes. 
The filters defined above only take into account the values of attributes with primitive 
types. However, attributes connecting components (either directly or mildly) to 
components containing particular content could work. In addition, filters that are based 
on attributes connecting targeted structures of sub-hypergraphs could be defined as well. 
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APPENDIX A. CAPS ACTORS 



1. ACTOR SUMMARY 

Actors axe the human or autonomous agents that exist outside the automation 
boundary for CAPS. The following table summarizes information about CAPS actors. 
The terms used in the table relate to the type of interaction the actor has with CAPS tools 
and information. 

Active/Passive refers to whether or not the actor initiates interaction with the 
tools and information. An active actor initiates the interaction while a passive actor 
responds when a request is forwarded only. 

Client/Non-client refers to whether or not the actor is using the tools for a 
particular purpose, or if they merely affect the system. 



Primary/Secondary indicates if the actor is one of the reasons for the system’s 
existence. The existence of an administrator is not a reason to have CAPS tools, but the 
administrator could play an important role. 





Acii\C'Piissi\c 


Clicni/Nonclicm 


Prinuin/ScconcbiA 


Project Manager 


Active 


Client 


Primary 


Requirements Analyst 


Active 


Client 


Primary 


Software Designer 


Active 


Client 


Primary 


Stakeholder 


Active 


Client 


Primary 


User 


Active 


Client 


Primary 


Administrator 


Active 


Client 


Secondary 


Analyst 


Active 


Client 


Primary 




Table A- J 


Actor Summary 
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Figure A-1 Actor Hierarchy 



2. ACTOR DESCRIPTIONS 

Project Manager (PM) is responsible for the execution of the project. The PM is 
concerned with scheduling individuals to tasks, reviewing the status of the project, and 
choosing between alternative solutions offered for each issue. 

Requirements Analyst (RA) is responsible for reviewing user comments and 
distilling out the issues to be resolved by system requirements. Alternative requirements 
or requirement changes are developed by RA for each issue. 

Software Designer (SD) attempts to satisfy requirements either through changes 
to existing components or the development of new software components. 

Stakeholder is an advisor to the project. Stakeholders effectively make up the 
projects board of directors. Stakeholders represent different interest groups within the 
project (e.g., users or sponsors). 

User is an individual being asked to try a prototype system and provide feedback. 
In a more mature system or in alternate methods, this system does not need to be a 
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prototype and the user can be any user of the software. Users operate the system and 
provide criticisms back to the project. 

Administrator takes care of the support software and database. Administrator 
sets up the schema, adds users to access lists, provides storage volumes to the database 
and performs other such tasks. The decision support system is not buOt for the 
administrator, but to make the system run smoothly and economicaUy it must be built with 
the administrator’s tasks in mind. 

Analyst is a generalization of all analytical actors. These include PM, RA, and 
SD. 
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APPENDIX B. USE CASE ANALYSIS 



The following use cases describe the requirements for the CAPS schema and run- 
time layer appUcations. The HOPE architecture is assximed and is therefore used within 
the requirements even though not a part of the target domain. 



1. USE SUMMARY AND RELATIONSHIPS 





Uses Tools Section(from Ch. IV) 


Actor 


U1 


U2, U3, Open and close session, add/edit component nodes, 
U4, U5 link nodes, delete component and link nodes. 


Project Manager 


U2 


None openSession 


Actor 


U3 


None Add/edit component nodes and link nodes, delete 

component nodes and link nodes. 


Analyst 


U4 


None Realize edits 


Analyst, 

Administrator 


US 


U4 Close a session, realize edits 


Actor 


U6 


U2, U3, Open and close session, add/edit component nodes, 
U4, U5 link nodes, delete component and link nodes. 


Project Manager 


U7 


U2, U4, Open and close session. Retrieve a component node 
U8 content. 


Software 

Designer 


U8 


None Retrieve component node content. 


Analyst 


U9 


None None 


Administrator 


UlO 


U2, U3, Open and close session, add/edit component nodes, 
U4, U5 link nodes, delete component and link nodes. 


Project Manager 


Ull 


U8 Open and close session, add/edit component nodes, 

link nodes, delete component and link nodes. 
Retrieve a component node content. 


User, 

Stakeholder 


U12 


U2, U3, Open and close session, add/edit component nodes, 
U4, U5, link nodes, delete component and link nodes, 
U8 retrieve a component node content. 


Requirements 

Analyst 


U13 


U2, U3, Open and close session, add/edit component nodes, 
U4, U5, link nodes, delete component and link nodes, 
U8, retrieve a component node content, calculate 

U14, distance, calculate complexity 

U15 


Requirements 

Analyst 


U14 


None Copy a component node with links in tact. 


Analyst 


U15 


None calculate distance, calculate complexity 


Analyst 


U16 


None Search for components and links 


Actor 


U17 


None View and filter the hypergraph 


Actor 
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Figure B-1 Use Case Relationships 



2. USE CASE SHEETS 



Use Case 


(L'l) Record Initial Requirements 


Actors 


Project Manager (PM) 


Preconditions 


A HOMIS must be established \sithin iIk- 1101*1 storage layer. 
The HOMIS has a schema defined approprute for CAPS and users 
defined to allow access to people in their appropriate roles. 
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Description 


The PM opens a session selecting the HOMIS for this software 
engineering project. The PM modifies the HOMIS, by adding 
components representing the initial requirements for the system. 
Requirement nodes are linked together where uses relationships 
occur to create a hierarchy of requirements. The PM can save the 
HOMIS periodically during the session. Upon ending the session, 
the PM is prompted to save the changes to the hypermedia system 
and exit. 


Sub Use Cases 


(U2) Open a session, (U3) Modify the HOMIS, (U4) Save Edits 
(U5) Close a session 


Exceptions 


There is no HOMIS available, or the HOMIS is locked for edit 
already (note that further work into merging hypermedia is 
required to allow concurrent use). 


Activities 




Postconditions 


Same as preconditions. 






Actors 


Actor 


Preconditions 


Users exist with appropriate permission to open a session. 


Description 


The actor requests a session with a HOMIS. A list of existing 
HOMIS are provided and the option to select one or create a new 
one providing a name for the HOMIS. The user selects the 
HOMIS for the project being analyzed. Actor is asked if this is to 
be an edit or read only session. If the user has appropriate 
permission, a session is opened. 


Sub Use Cases 


None 


Exceptions 


(El) User does not have permission to open the selected session 
with the HOMIS desired. No session is opened if this is the case. 
Message is sent to Administrator. 


Activities 


none 


Postconditions 


A session is opened to the HOMIS selected. 




(U.i) Modify the project database HOMIS 


Actors 


Analyst 


Preconditions 


Analyst has an open edit session with the required HOMIS. 


Description 


Analyst sees a hypergraph view of the project database. The 
analyst creates new component nodes representing criticisms. 



95 





Sub Use Cases 


issues, requirements, or designs and links them to other nodes with 
which they are associated. Links are also made with nodes that 
already exist. Deletion of components and links are also done as 
part of the analysis. 

None 


Exceptions 


None 


Activities 


None 


Postconditions 


None 




(U4) Save Edits 


Actors 


Analyst, Administrator 


Preconditions 


Analyst has an open session with a HOMIS. Changes have been 
made. 


Description 


Analyst requests that edits be saved. System persists the new copy 
of the HOMIS 


Sub Use Cases 


None 


Exceptions 

Activities 


None 

None 


Postconditions 


Persistent copy of the HOMIS now reflects state as currently 
viewed by the user. (Note later approach may include merging 
hypermedia versions to allow concurrent edits). 




(U5) Close a Session 


Actors 


Actor 


Preconditions 


Actor has an open session with a HOMIS. 


Description 


Actor requests that session be closed. Actor is given the choice to 
save edits if the session is an edit session. Edits are realized if 


Sub Use Cases 


necessary and the session is closed. 
(U4) Save Edits 


Exceptions 


None 


Activities 


None 


Postconditions 


Session is closed. 




(U6) Design Prototype 


Actors 


Project Manager 
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Preconditions 


A HOMIS exists for the project database under consideration. 


Description 


The project manager allocates requirements to system design 
components by either linking requirements to existing components 
or creating new design components and Unking them to the 
requirements. Design components may be Unked to each other to 
provide uses relationships among the components. 


Sub Use Cases 


(U2) Open session, (U3) Modify HOMIS, (U4) Save Edits, (U5) 
Close session. 


Exceptions 

Activities 


None 

None 


Postconditions 


Session is closed. 


Use Case 


(L'7) Design Software 


Actors 


Software Designer 


Preconditions 


A HOMIS exists for the project database under consideration. At 
least one design component has been generated and is related to at 
least one requirement (there is a path to a requirement). 


Description 


The software designer (SD) opens a read only session (this does 
not require a lock on the hypertext, it is merely used to retrieve a 
component for edit - the editor determines locking on the content) 
to the HOMIS and retrieves the software component for edit. By 
opening the node for edit, the PSDL editor is launched and the 
designer creates and modifies the design. The PSDL editor is used 


Sub Use Cases 


to store content changes. 

(U2) Open session, (U8) Retrieve a Component, (U5) Close 
session. 


Exceptions 

Activities 


None 

None 


Postconditions 


Session is closed. 




(U8) Retrieve a Component 


Actors 


Actor 


Preconditions 


A session is open with a HOMIS. 


Description 


The actor selects a component through one of many user interface 
options and chooses to retrieve the contents for either viewing or 
editing. The presentation specification of the component is used 
to launch an appropriate appUcation to work with the content. 


Sub Use Cases 


None 
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Exceptions 


(E2) Anchor link to content does not exist. 


Activities 


None 


Postconditions 


A session is open with a HOMIS. 






Actors 


Administrator 


Preconditions 


None 


Description 


The administrator opens the log and is able to view all entries. No 
edit capability is given. The administrator my delete or copy the 
entire log. 


Sub Use Cases 


None 


Exceptions 

Activities 


None 

None 


Postconditions 


None 






Actors 


Project Manager 


Preconditions 


A HOMIS representing the project database is present in the 
HOPE. 


Description 


The project manager opens an edit session with the HOMIS. By 
adding a demonstration node to the hypergraph, the demonstration 
is created. The project manager then links design components, 
requirements, issues, or criticisms with the demonstration. Since 
paths exist from all design components all the way back to 
requirements and through all issues and criticisms addressed to the 
users, any user may determine what is being demonstrated. 
Demonstration scenarios are also linked to the node. These also 
refer back to requirements and therefore to the other nodes 
connected to them. When finished, the project manager saves the 
edits and closes the session. 


Sub Use Cases 


(U2) Open a session, (U3) Modify the HOMIS, (U4) Save Edits 
(U5) Close a session 


Exceptions 


None 


Activities 


None 


Postconditions 


A demonstration node exists. 
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1 I'se Case 


(LM 1 ) Submit Criticism 1 


Actors 


User and Stakeholder 


Preconditions 


A demonstration exists in the HOMIS. 


Description 


The user or stakeholder opens a session with the HOMIS. A new 
criticism component is created and the contents are modified to 
reflect the users criticism. The user/stakeholder links the criticism 
(this could be done automatically by the user interface) to a 
particular demonstration scenario. The criticism is automaticaUy 
linked to the user by the runtime layer application making the 
appropriate requests of the storage layer. The changes are saved 
and the session is closed. 


Sub Use Cases 


(U2) Open a session, (U3) Modify the HOMIS, (U4) Save Edits 
(U5) Close a session, (U8) Retrieve a Component 


Exceptions 


None 


Activities 


None 


Postconditions 


A new criticism node now exists.. 






Actors 


Requirements Analyst 


Preconditions 


A criticism exists within the HOMIS representing the project 
database. 


Description 


The requirements analyst opens a session with the HOMIS. 
Retrieving the criticism and reading it. the analyst either creates 
and adds text to a new issue component node, then links it to the 
criticism, or links the criticism to an exi.stinp issue node. The 


Sub Use Cases 


changes are saved and the session is closed 

(U2) Open a session, (U3) Modify the HOMIS. (U4) Save Edits 

(U5) Close a session, (U8) Retrieve a C\>mp*>nent 


Exceptions 


None 


Activities 


None 


Postconditions 


A new criticism node now exists.. 




(L 13) Explore Alternatives 


Actors 


Requirements Analyst 


Preconditions 


An issue to be resolved exists within tlK- II ONI IS representing the 
project database. 
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Description 


The requirements analyst opens a session with the HOMIS. 
Retrieving the issue and reading it, the analyst either creates and 
adds text to new requirement component nodes, then links them to 
the issue, or links the issue to existing requirement nodes. 
Requirement nodes can also be copied and edited creating new 
versions of these requirements. The other links of the copied 
requirement must also be copied to the new node. These 
requirements must have a relationship with the original 
requirement illustrating the update. Multiple alternative solution 
relationships can be set up between issues and collections of 
requirements. Distance and complexity calculations are performed 
on each alternative to help make a decision. When a decision is 
made one alternative relation is changed to a uses relation. The 
changes are saved and the session is closed. 


Sub Use Cases 


(U2) Open a session, (U3) Modify the HOMIS, (U4) Save Edits 
(U5) Close a session, (U8) Retrieve a Component, (U14) Copy a 
node with links intact, (U 1 5) Calculate distance and complexity 


Exceptions 

Activities 


None 

None 


Postconditions 


A new criticism node now exists.. 






Actors 


Analyst 


Preconditions 


A component node exists in the HOMIS. An edit session is open. 


Description 


The analyst selects a component node to be copied. A new node 
is placed in the hypergraph with links in place to all nodes linked 
by the original object. A link from the original to the copy is 
automatically created indicating that this is an updated version. 


Sub Use Cases 


None 


Exceptions 

Activities 


None 

None 


Postconditions 


A new node now exists.. 






Actors 


Analyst 


Preconditions 


A component node exists in the HOMIS. An session is open. 



100 







Description 


The analyst selects a component node to be analyzed. The 
distance from the selected node to all leaf nodes, where no mildly 
connected paths are followed, is calculated. The longest distance 
is returned. The total number of links directed out from the node 
selected to leaf nodes is counted (again, no mildly connected paths 
are followed). This number is returned as the complexity. 


Sub Use Cases 


None 


Exceptions 


None 


Activities 


None 


Postconditions 


None 



Use Case 


(L.M6) Search 


Actors 


Actor 


Preconditions 


A session is open. 


Description 


The user determines first if the result of the search should be 
component nodes or links. The actor is then queried for attribute 
and content values that can be used to match the targets. A set of 
objects is returned to the actor. 


Sub Use Cases 


None 


Exceptions 


None 


Activities 


None 


Postconditions 


None 



Use Case 


(Li 17) View and filter the hyperuraph 


Actors 


Actor 


Preconditions 


A session is open 


Description 


The actor determines what types of nodes and what values of 
component and link nodes are of interest. For instance, a user may 
wish to only see criticisms and resulting issues that were posed by 
the user. 


Sub Use Cases 


None 


Exceptions 


None 


Activities 


None 


Postconditions 


None 
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3. EXCEPTIONS 



Exception 


(E 1 ) Permission Denied 


Actors 


Exception 


Preconditions 


A request has been made to open a session to a HOMIS without 
adequate permission. 


Description 


The user is informed that the operation cannot proceed. A 
message is sent to the system administrator’s log. 


Sub Use Cases 


None 


Exceptions 


None 


Activities 


None 


Postconditions 


No session is opened. 




Exception 


(E2) Anchor Link is Broken 


Actors 


Exception 


Preconditions 


A request has been made to open the content of a node. No valid 
anchor link exists. 


Description 


The user is informed of the lack of an anchor. The node is 
removed from the hypermedia system. A message is sent to the 
administrator. 


Sub Use Cases 


None 


Exceptions 


None 


Activities 


None 


Postconditions 


The offending node is no longer in the hypermedia system. This is 
true regardless of the type of session that is open. 
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